L’analyse du PC de la RH a révélé comment l’attaquant s’est propagé dans le réseau et a identifié sa nouvelle cible : le PC du PDG. Ce dernier contient de nombreuses informations confidentielles et devra maintenant être examiné en détail.
L'attaquant a compromis l'ordinateur du PDG et a réussi à exfiltrer des données sensibles de l'entreprise. Vous disposez uniquement de la capture mémoire de la machine infectée. Votre mission est d'analyser cette capture pour identifier les méthodes de collectes et d'exfiltration utilisées. Il se pense plus malin que vous, mais peut-être a-t-il fait une erreur qui vous permettra de retrouver sa véritable identité ?
À partir du dump de la mémoire du serveur attaqué durant ladite attaque,
nous pouvons voir les différents processus qui étaient lancés, par
exemple grâce à l'outil Volatility. Nous pouvons isoler le processus
correspondant au virus, mais cette étape n'est pas nécessaire pour
réussir la suite, elle permet juste d'échantillonner le volume sur
lequel travailler.
Nous cherchons une clé AES qui a permis de chiffrer les différents
fichiers. À partir de l'étape de rétro-ingénierie, il est possible de trouver
les différentes informations vis-à-vis de la génération de la clé :
- Utilisation de CALG_AES_256.
- Utilisation de PLAINTEXTKEYBLOB.
À partir de la documentation
https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/ns-wincrypt-publickeystruc,
nous pouvons voir que le contenu en mémoire de la clé est précédé
par bType, bVersion, reserved et aiKeyAlg. Toujours d'après
la documentation, nous avons ainsi :
- 0x08 pour PLAINTEXTKEYBLOB,
- 0x02 pour la version (ou 0x03 les deux seules valeurs existantes),
- 0x0000 pour un espace réservé qui doit être mis à 0,
- 0x10660000 pour CALG_AES_256 (d'après https://learn.microsoft.com/en-us/windows/win32/seccrypto/alg-id),
- 0x20000000 pour la taille de la clé.
Nous avons donc la signature 0802 0000 1066 0000 2000 0000 précédant
les clés AES du même type que celle cherchée. Si l'on cherche cette
occurrence dans le dump du processus correspondant au binaire
récupéré (à l'aide par exemple de xxd et grep), nous trouvons
un seul résultat précédant la clé AES.
Nous pouvons l'utiliser pour déchiffrer, avec par exemple un script
Python et en utilisant openssl, des différents fichiers chiffrés.
Après avoir déchiffré les logs d'évènements Windows et les logs du
pare-feu local, nous pouvons retracer l'activité de la machine avant
l'attaque.
On retrouve un ensemble de log permettant de trouver l'origine de l'attaque.
Tout d'abord, on voit que jre-8u101-windows-64bit.exe est exécuté, ce qui
nous permet de confirmer qu'il est le virus.
Ensuite, il est possible de voir un ensemble d'action autour des 3 fichiers
suivants :
- adobe-v2.4.exe,
- jre-8u101-windows-64bit.exe.
En effet, on comprend grâce aux logs que ces fichiers sont
dans le dossier C:\Windows\SoftwateDistribution\Download\Install\.
Ce qui nous laisse penser qu'ils sont en lien avec le processus de
mise à jour de Windows.
Par ailleurs, les logs montrent une copie via un partage réseau
sur le fichier .cab contenant le virus.
En remontant les logs, on découvre des logs liés au Windows Update
Agent, qui détecte une mise à jour. Cette mise à jour est le vecteur
d'introduction de adobe-v2.4.exe sur le serveur compromis.
Cet exécutable est le point d'entrée pour l'exécution du virus.
L'ensemble de ces éléments nous permet de comprendre, que
le vecteur d'attaque est le service de mise à jour de Windows.
En analysant les logs Windows fourni on peut trouver un ensemble d'élément
intéressants.
À noter que ce document traite les évènements du plus au moins récents.
Dans un premier temps, il est possible de faire une passe rapide sur les logs pour
savoir qui a administré le serveur, on remarque 2 utilisateurs :
- master,
- e_smith.
Sachant des étapes précédentes que e_smith, et l'attaquante sur le SI, on peut
donc se concentrer sur les logs qui la concerne.
Tout d'abord, on remarque l'ajout de l'utilisateur p_louis au groupe Domain Admins.
Cet événement isolé ne nous permet aucune conclusion tel quel.
Par la suite, on remarque un premier log concernant le service WSUS.
Un second log vient confirmer ce que nous avions trouvé à l'étape précédente,
l'attaquant a bien utilisé le service WSUS pour propager le virus.
Ensuite on voit un log d'accès au virus par le service WSUS Package Publisher,
pour le fichier C:\WSUS\Custom Update\jre-8u101-windows-64bit.exe. Cela nous
donne un premier indice sur l'origine du virus.
En continuant l'analyse, nous constatons une série de logs de duplication de handle
vers le dossier C:\WSUS\Custom Update, ce qui laisse penser à une copie des fichiers
de mise à jours.
Finalement, le dernier log nous permet de comprendre l'origine du virus.
Enfin, nous pouvons corréler l'heure du branchement de la clé USB avec les
données du fichier csv des accès à la salle serveur. Nous pouvons trouver
le jour même seulement deux entrées, dont une seulement quelques minutes
avant le branchement de la clé USB, et l'autre bien après. Ce premier accès
correspond donc à celui de l'attaquant, et nous retrouvons le nom de notre
suspect initial.