Après avoir découvert que le PC de Thomas était infecté, une question persiste : comment l'attaquant a-t-il eu accès aux données du labo?
L'infiltration du laboratoire IRBF a franchi une nouvelle étape. L'assaillant, après avoir réussi à pénétrer notre Active Directory grâce à un document Excel piégé et à établir une tête de pont avec un reverse shell HTTP, détient désormais un accès sur l'une de nos machines. La question cruciale demeure : comment a-t-il, à partir de là, **escaladé ses privilèges** pour finalement compromettre notre **base de données** ?
Chaque log, chaque enregistrement de notre AD est devenu une pièce du puzzle. Nous devons reconstituer le chemin parcouru par l'attaquant : les mouvements latéraux, les tentatives de reconnaissance, l'exploitation de failles, les exfiltrations potentielles d'identifiants... Tout ce qui a pu lui permettre de passer d'un simple accès machine à la mainmise sur nos données les plus sensibles doit être mis en lumière. Les moindres traces de son passage sont notre seule chance de comprendre et, espérons-le, de sécuriser notre infrastructure.
En analysant les logs, on peut voir un nombre important d'événements 4769
signifiant de nombreuses requêtes de tickets Kerberos.
Un outil tel que hayabusa permet de trouver des indices sur l'attaque utilisée.
# Ici sur les logs du DC
$ hayabusa json-timeline -d Log_DC/ -L -o Log_DC/timeline.jsonl -w -U -p super-verbose
Les logs Kerberos sont stockés sur le contrôleur de domaine.
Voici une façon de chercher:
$ hayabusa search -d Log_DC --keyword 4769 --keyword ticket
[!IMPORTANT]
Le format de la date est en UTC,
La conversion peut se faire avec hayabusa:hayabusa search ... --UTC
Ce qui donne, entre autres, une série de requêtes de tickets de service Kerberos :
On remarque une fréquence très élevée de ces tickets, typique de l'attaque
cherchée.
Les logs sont horodatés et on peut voir qu'un nombre important d'événements 4769
a eu lieu le 11 juin à 00h03.
À la suite de cette attaque, on peut voir sur les logs du PC
qu'un utilisateur inhabituel s'est connecté depuis le PC du stagiaire. On peut
donc en déduire l'utilisateur usurpé.
L'outil takajo donne les connexions au PC du stagiaire, à partir du fichier
timeline.jsonl généré par hayabusa:
$ ./takajo timeline-logon -t Log_PC/timeline.jsonl -o logon_timeline_pc.csv
Nous devons ouvrir l'exécutable dans un décompilateur comme Ghidra.
Nous sommes maintenant dans le programme principal de l'exécutable. Nous pouvons voir qu'il y a des appels aux fonctions socket et closesocket, ainsi qu'à la fonction qui permet de s'y [FLAG]. Ces fonctions sont typiques d'un reverse shell.
Comme nous l'avons vu précédemment, nous avons identifié l'appel système pour se [FLAG] à un socket.
On peut voir la fonction CreateProcessA qui est utilisée avec la variable local_10.
Cette variable est une chaîne de caractères qui contient le nom de l'exécutable à exécuter.
On voit plusieurs caractères de la chaîne qui sont remplacés par des valeurs.
En la reconstruisant, on peut voir que l'exécutable est le cmd de Windows.
Ci-dessous, des valeurs sont stockées dans une structure qui sera donnée en paramètre. D'après les décalages d'adresse, les valeurs ne sont pas dans l'ordre mémoire de la structure.
Ensuite, 2 appels de fonctions sont réalisés pour préparer l'IP et le port de l'appel à socket.
En analysant le code assembleur de la fonction qui génère l'adresse IP, on observe la séquence suivante :
EAX = EBP + Stack[0x4] et application de transformations :EAX + 0xc : C'est le 4ème entier de la structure.EAX + 0x8 : Récupère la valeur du 3ème entier et soustrait 5.EAX + 0x4 : C'est la seconde valeur de la structure.EAX : Récupère la première valeur de la structure et soustrait 30.
Les valeurs sont ensuite formatées dans une chaîne "%u.%u.%u.%u" pour construire l'adresse IP.
D'après les valeurs initiales, l'adresse IP résultante est 203.0.113.12.
La fonction ci-dessous calcule le port :
Cette fonction :
1. Accède à deux valeurs à partir d'un paramètre :
- L'offset 0x10 (16 en décimal) : correspond à la 5ème valeur de la structure.
- L'offset 0x14 (20 en décimal) : correspond à la 6ème valeur.
Retourne la somme de ces valeurs.
Dans le code source, 80 et 9, donc le port calculé est 91
Le port final est 8000 + 89 = 8089.