DarkWidow

Un outil dropper personnalisable ciblant Windows.

Mentions honorables :

Un grand merci à Soumyadeep Da alias @SoumyadeepBas12 pour m'avoir encouragé à postuler à ces conférences, sinon je ne l'aurais pas fait :)
Un grand merci à Faran alias @Chrollo_l33t pour m'avoir aidé à créer les diapositives et le PPT pour la présentation de cet outil :)

Capacités :

Syscall dynamique indirect. (MITRE ATT&CK TTP: T1106)
Tri des adresses SSN + Syscall via l'approche TartarusGate modifiée
Injection de processus distant via APC Early Bird pour couper la capture de télémétrie par l'EDR. (MITRE ATT&CK TTP: T1055.004)
Lance un processus sacrifié comme processus cible, sans perturber les processus déjà ouverts dans l'environnement.
Politique d'atténuation ACG (Arbitrary Code Guard)/BlockDll sur le processus sacrifié lancé.
Usurpation de PPID (MITRE ATT&CK TTP: T1134.004)
Résolution d'API et de DLL depuis TIB (directement via offset (depuis TIB) -> TEB -> PEB -> résoudre Nt Api) (MITRE ATT&CK TTP: T1106)
Hachage Nt API maudit (MITRE ATT&CK ID: S0574)

Bonus : Avec privilège Admin =>

Désactive le journal des événements en tuant les threads du service EventLog (MITRE ATT&CK TTP: T1562.002)

Inconvénient : Si les threads sont repris, tous les événements survenus pendant la suspension du journal des événements sont à nouveau enregistrés !

Donc, j'ai pensé à les tuer à la place !

"C'est plus invasif que la suspension, mais la décision revient toujours à l'opérateur. De plus, tuer des threads est journalisé au niveau du noyau" - @SEKTOR7net

Alors que tuer uniquement ces threads dans l'implant syscall indirect posait une erreur. Je n'ai pas pu obtenir la valeur SubProcessTag de "eventlog". J'ai donc pensé à tuer tous les threads, c'est-à-dire tuer tout le processus (le svchost.exe responsable). Oui, créer un IOC !.

=

1. Contournement des hooks EDR/Ring-3/UserLand

2. Le syscall et l'instruction return sont exécutés depuis la mémoire de ntdll.dll

3. La détection EDR basée sur la vérification de l'adresse de retour dans la pile d'appels peut être contournée.

Compilation :

Directement via le compilateur VS :

Ajoutez également le flag du compilateur /MT ! => Pour lier statiquement les fonctions CRT dans un binaire (Oui, vous l'avez deviné, cela gonfle l'implant)

Aussi via compile.bat (préférez l'option 1.)

./compile.bat

Utilisation :

PS C:> .\x64\Release\indirect.exe
[!] Wrong!
[->] Syntax: .\x64\Release\indirect.exe <PPID to spoof>

En action :

https://github.com/reveng007/DarkWidow/assets/61424547/62a90c5b-84af-4389-8ddc-9f7926debdcf

Exécution réussie sans créer d'alerte sur le point de terminaison Sophos XDR :

SofosXDREvade

Améliorations futures :

Usurpation de PPID (méthode Emotet)
Cas d'utilisation beaucoup plus furtif de désactivation du journal des événements !

Portions du code et liens qui ont aidé :

TIB :
- https://en.wikipedia.org/wiki/Win32_Thread_Information_Block
- https://www.wikiwand.com/en/Win32_Thread_Information_Block
Registres GS et FS :
- https://stackoverflow.com/questions/39137043/what-is-the-gs-register-used-for-on-windows
- https://stackoverflow.com/questions/10810203/what-is-the-fs-gs-register-intended-for#:~:text=The%20registers%20FS%20and%20GS,to%20access%20thread%2Dspecific%20memory.
Structure PEB LDR :
- BlackHat - What Malware Authors Don't Want You to Know - Evasive Hollow Process Injection par @monnappa22
- Une image de la mémoire du processus depuis le lien ci-dessus :
- Depuis labs.cognisys.group, un blog de @D1rkMtr :
TIB -> TEB -> PEB -> Résoudre Nt API et hachage d'API


#include <stdint.h>
#include <stdio.h>
#include <Windows.h>

DWORD64 djb2(const char* str)
{
	DWORD64 dwHash = 0x7734773477347734;
	int c;

	while (c = *str++)
		dwHash = ((dwHash << 0x5) + dwHash) + c;


	return dwHash;
}

int main(int argc, char** argv)
{
	if (argc < 2)
	{
		printf("[!] Wrong!\n");
		printf("[->] Syntax: .\\%s <NTFuncName>\n\n", argv[0]);
		return 1;
	}

	const char* string = argv[1];

	DWORD64 hashvalue = djb2(string);

	printf("Hash Value: 0x%llX\n", hashvalue);

	return 0;
}

Politique d'atténuation ACG (Arbitrary Code Guard)/BlockDll :
- liens :
- Protecting Your Malware par @xpn
- Wraith par @winterknife
- spawn et HOLLOW par @0xBoku
Détection de l'usurpation de PPID :
- PPID Spoofing Detect par @spotheplanet
- Si j'ai le temps, j'ajouterai une partie de détection à cette section ! -> [Restant................................................!]
Détection Moneta et PESieve :\
- Moneta :
- PESieve :
Scan Capa :
À quoi ressemble la pile de threads du processus implant :

Processus implant	Processus Cmd légitime

Il s'ensuit qu'en exécutant l'instruction return dans la mémoire de ntdll.dll dans le POC syscall indirect, l'adresse de retour peut être usurpée avec succès, la ntdll.dll peut être placée en haut de la pile d'appels et l'EDR interprétera une légitimité plus élevée. - @VirtualAllocEx de DirectSyscall Vs Indirect Syscall
Merci également à @peterwintrsmith !

Évitement du rappel d'instrumentation : Utilisé ce POC - syscall-detect par winternl_t

Configuration du journal des événements que j'ai utilisée :

alt text

Configuration du privilège SeDebugPrivilege :
Depuis ici : Jusqu'à ici :
Tuer les threads du journal des événements :
- rto-win-evasion par @SEKTOR7net
- Phant0m par @hlldz
- Goblin par @winterknife
- disabling-windows-event-logs-by-suspending-eventlog-service-threads par @spotheplanet
  Depuis ici :
  
  Jusqu'à ici :
- Cette méthode a fini par causer des erreurs dans l'implémentation du syscall indirect. J'ai donc fini par tuer tous les threads présents dans le svchost.exe responsable (raison : Remonter).

Scénario de journalisation des événements Sophos XDR :

Cas 1 : DarkWidow exécuté sous privilège normal

Aucune alerte critique créée, sauf un journal de faible gravité !

Cas 2 : DarkWidow exécuté sous privilège Admin

Un journal de faible gravité => Injection APC (Comme avant)

Un autre journal de gravité moyenne est apparu pour la configuration du SeDebugPrivilege.

DarkWidow V2 :

Pour contourner cette détection de journalisation des événements, j'ai ajouté le concept de `Synthetic Frame Thread Stack Spoofing`.

Voici à quoi ressemble la pile après application du Synthetic Frame Thread Stack Spoofing.

Ceci est la pile de threads de l'API NT

Ceci est la pile de threads de la shellcode (d'ailleurs, ce n'est pas du sur-mesure, c'est la shellcode Havoc :))

Pour le développement de la shellcode, j'ai utilisé havoc et la configuration ci-dessous :

REMARQUE :

L'usurpation de l'adresse de démarrage d'un thread nouvellement créé n'était pas vraiment nécessaire dans ce projet car dans la technique d'injection APC, l'APC détourne l'exécution d'un thread déjà existant et légitime. Merci à @C5pider !

Image d'exécution de démonstration :

1708744707672

Vidéo de démonstration contre Sophos XDR :

État actuel des journaux d'événements ?

Aucun journal généré. J'ai également supprimé la partie de suppression du journal des événements dans DarkWidow V2, ce qui réduit également la génération d'événements !

Ma vidéo de démonstration BlackHat Arsenal peut être trouvée ici :

Ma diapositive de présentation WildWestHackinFest et le lien vidéo peuvent être trouvés ici :

Mises à jour futures pour cela :

Portage de cette version vers le compilateur C++ Clang, ce qui nous aiderait à effectuer l'obfuscation LLVM.
Mise à niveau vers NtCreateUserProcess() pour effectuer un syscall indirect et un stack spoofing.
Application de la capacité de chargement manuel de bibliothèque pour contourner les rappels de chargement d'image du noyau.
Application de la capacité de module stomping.
Injection de shellcode chiffrée pour éviter les analyses mémoire déclenchées par le noyau (Caro-Kann).

Détection de la technique de stack spoofing (comme mentionné dans l'un de mes ateliers/présentations) :

Un grand merci à ceux qui m'ont aidé (directement/indirectement (jeu de mots non intentionnel :))) :

J'espère n'avoir oublié personne !

DarkWidow

Populaires

À propos

DarkWidow

Populaires

À propos

DarkWidow

Mentions honorables :

Capacités :

Bonus : Avec privilège Admin =>

Alors que tuer uniquement ces threads dans l'implant syscall indirect posait une erreur. Je n'ai pas pu obtenir la valeur SubProcessTag de "eventlog". J'ai donc pensé à tuer tous les threads, c'est-à-dire tuer tout le processus (le svchost.exe responsable). Oui, créer un IOC !.

=

1. Contournement des hooks EDR/Ring-3/UserLand

2. Le syscall et l'instruction return sont exécutés depuis la mémoire de ntdll.dll

3. La détection EDR basée sur la vérification de l'adresse de retour dans la pile d'appels peut être contournée.

Compilation :

Ajoutez également le flag du compilateur /MT ! => Pour lier statiquement les fonctions CRT dans un binaire (Oui, vous l'avez deviné, cela gonfle l'implant)

Utilisation :

En action :

Exécution réussie sans créer d'alerte sur le point de terminaison Sophos XDR :

Améliorations futures :

Portions du code et liens qui ont aidé :

Scénario de journalisation des événements Sophos XDR :

DarkWidow V2 :

Pour contourner cette détection de journalisation des événements, j'ai ajouté le concept de Synthetic Frame Thread Stack Spoofing.

REMARQUE :

Image d'exécution de démonstration :

Vidéo de démonstration contre Sophos XDR :

Ma vidéo de démonstration BlackHat Arsenal peut être trouvée ici :

Ma diapositive de présentation WildWestHackinFest et le lien vidéo peuvent être trouvés ici :

Mises à jour futures pour cela :

Détection de la technique de stack spoofing (comme mentionné dans l'un de mes ateliers/présentations) :

Un grand merci à ceux qui m'ont aidé (directement/indirectement (jeu de mots non intentionnel :))) :

Ce projet fait partie de mon parcours d'apprentissage du monde de l'EDR ! => Learning-EDR-and-EDR_Evasion

Pour contourner cette détection de journalisation des événements, j'ai ajouté le concept de `Synthetic Frame Thread Stack Spoofing`.