Afin de poursuivre l’investigation sur le poste compromis, un dump mémoire complet de la machine a été collecté pour analyse.
Les enquêteurs souhaitent comprendre si des activités suspectes se sont produites sur le système et déterminer leur nature.
Un dump mémoire complet du poste de l’employé a été collecté afin d’investiguer des comportements inhabituels.
Vous devez analyser cette capture pour identifier les activités suspectes pouvant indiquer un accès maintenu au système.
vol -f memory.dmp windows.info.Info
D'après la sortie de cette commande, nous pouvons en conclure :
Informations système :
- OS : Windows 11 x64 (Build 26100, Is64Bit: True)
- Version : Windows 11 24H2 (Build 26100)
- Architecture : x64 (Machine Type: 34404)
- Processeurs : 5 cœurs (KeNumberProcessors: 5)
- Type de produit : NtProductWinNt (Windows workstation, pas un serveur)
Informations temporelles critiques :
- Horodatage système : 2025-09-09 21:16:50 UTC
- Cette information est cruciale, car elle nous donne le moment exact où le dump mémoire a été pris
Informations techniques :
- Kernel Base : 0xf805ae200000
- DTB (Directory Table Base) : 0x1be000
- Architecture 64 bits confirmée sans PAE
Ainsi on sait maintenant quel profil utiliser pour la suite de l'analyse.
vol -f memory.dmp windows.pslist.PsList
L'analyse des processus révèle un environnement Windows 11 standard avec les processus système habituels (System, Registry, csrss.exe, winlogon.exe, services.exe, lsass.exe, etc.) et des applications utilisateur normales (explorer.exe, msedge.exe, OneDrive.exe).
Processus d'intérêt :
- powershell.exe (PID 4852) - Démarré à 21:13:20 UTC avec 12 threads
- conhost.exe (PID 7472) - Console host pour PowerShell
- msedge.exe - Plusieurs instances de Microsoft Edge
- OneDrive.exe - Application de synchronisation
Le processus PowerShell est particulièrement intéressant car :
1. Il a été lancé vers 21h13, soit environ 3 minutes avant le dump mémoire
2. Il s'agit d'un vecteur d'attaque commun
Nous devons analyser plus en détail ce processus PowerShell.
vol -f memory.dmp windows.cmdline.CmdLine --pid 4852
Résultat :
PID Process Args
4852 powershell.exe "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
PowerShell a été lancé sans arguments spécifiques visibles, ce qui suggère une exécution interactive ou via un script.
vol -f memory.dmp windows.dlllist.DllList --pid 4852
Analyses importantes des DLL chargées :
On ne remarque aucune DLL suspecte ou non standard.
vol -f memory.dmp windows.netscan.NetScan
Note : Rien de concluant n'a été trouvé dans les connexions réseau actives, mais nous avons pu extraire le dump mémoire du processus.
vol -f memory.dmp windows.pslist.PsList
On suit notre piste du powershell.exe (pid 4852) et on voit qu'il y a un conhost.exe (pid 7472) qui lui est rattaché.
Mais surtout que son parent est explorer.exe (pid 5656) ce qui n'est pas normal.
Ainsi on peut penser que le poste a été compromis par un utilisateur qui a lancé une session powershell depuis l'explorer.exe.
Reste à savoir comment il a pu faire ça.
vol -f memory.dmp windows.dlllist.DllList --pid 5656
On n'obtient rien de concluant.
Ainsi on repart de l'analyse des processus, cette fois on va regarder les processus enfants de explorer.exe (pid 5656).
vol -f memory.dmp windows.pslist.PsList | grep "5656"
vol -f memory.dmp windows.pslist.PsList | grep "5656"
5656 5620 explorer.exe 0xcb04f2c5f080 66 - 1 False 2025-09-09 21:10:49.000000 UTC N/A Disabled
7548 5656 SecurityHealth 0xcb04f2db5080 2 - 1 False 2025-09-09 21:11:01.000000 UTC N/A Disabled
8160 5656 msedge.exe 0xcb04f1b09240 0 - 1 False 2025-09-09 21:11:17.000000 UTC 2025-09-09 21:13:28.000000 UTC Disabled
5936 5656 OneDrive.exe 0xcb04f27df080 25 - 1 False 2025-09-09 21:11:22.000000 UTC N/A Disabled
4852 5656 powershell.exe 0xcb04ef6d6080 12 - 1 False 2025-09-09 21:13:20.000000 UTC N/A Disabled
9096 5656 msedge.exe 0xcb04efde60c0 56 - 1 False 2025-09-09 21:13:58.000000 UTC N/A Disabled
Ainsi on voit que le processus powershell.exe (pid 4852) est bien un enfant d'explorer.exe (pid 5656).
Mais surtout que d'autres processus le sont et sont donc peut-être la source de la compromission.
On peut maintenant avoir deux logiques :
Soit le processus powershell.exe (pid 4852) a été lancé après la création d'un autre processus enfant d'explorer.exe (pid 5656) et c'est ce processus qui est la source de la compromission.
Soit le processus powershell.exe (pid 4852) a été lancé pendant la création d'un autre processus enfant d'explorer.exe (pid 5656) et c'est ce processus qui est la source de la compromission, étant donné que seul un processus correspond à cette option, on va partir sur cette piste en premier quitte à revenir en arrière si besoin.
vol -f memory.dmp windows.dlllist.DllList --pid 9096
vol -f memory.dmp windows.dlllist.DllList --pid 9096 | awk '{print $5}' | grep -v "^Name$" | grep -v "^$" | sort | uniq
On constate la présence d'un fichier intitulé well_known_domain.DLL avec l'extension en majuscule : cela attire notre curiosité.
Ainsi on va essayer de récupérer cette DLL ainsi que l'autre avec un nom similaire via:
vol -f memory.dmp -o dumps windows.dlllist.DllList --pid 9096 --dump # nécessite un dossier dumps
On obtient toutes les DLLs du process et notamment les 2 qui nous intéressent.
Commençons par le fichier well_known_domain.DLL, en faisant une simple commande strings on ne constate rien de concluant, à part la présence d'un nombre 4333 qui peut faire penser à un port réseau mais aucune certitude.
Avant de l'ouvrir dans ghidra, on va regarder la seconde DLL suspecte : well_known_domains.dll.
En effectuant un simple strings dessus, on constate la présence d'une adresse IP et d'une référence à PowerShell ainsi que d'autres chaînes de caractères intéressantes comme socket, recv, send, connect...
On peut ainsi penser que cette DLL a été injectée dans le processus msedge.exe (pid 9096) pour exécuter des commandes PowerShell : cette méthode d'attaque est connue sous le nom de DLL injection sauf que dans notre cas, la présence de deux fichiers similaires laisse penser à une technique de DLL proxying.
On suppose fortement donc l'utilisation d'un reverse shell grâce à la présence d'une adresse IP.
Le port nous est maintenant demandé, on peut penser que c'est le nombre 4333 vu dans l'autre DLL.
Mais pour en être sûr, on va analyser cette DLL.
On ouvre donc le fichier dans Ghidra et on avance après l'entry point et on reconnait l'adresse IP ainsi que la chaîne de caractères qu'on a constaté auparavant grâce à la commande strings :
On continue de fouiller le code décompilé et on peut identifier des fonctions liées à la création de sockets, la connexion à une adresse distante, l'envoi et la réception de données mais surtout on trouve le port utilisé pour la connexion.
Nous avons donc identifié la méthode de persistance utilisée ainsi que l'adresse IP et le port de destination.