Le premier avril, le site marchand de Sparklez ne semble plus être accessible, et ne renvoie que des erreurs 503... On dirait une mauvaise blague. Sparklez comprend assez vite qu'ils sont victimes d'une attaque par déni de service.
Vis-à-vis du contexte tendu avec IncRizz, tout porte à suspecter une vengeance venant d'un de ces ex-employés...
Avec les logs du serveur lors du déni de service et la page publique du réseau social préférée des employés d'IncRizz, FilouBook, sur laquelle chacun publie régulièrement des posts, identifiez un suspect derrière cette attaque.
La première étape correspond à lire le fichier log.
On constate que le format du fichier est un format de log de dnsmasq.
On peut y voir des requêtes DNS, la plupart étant de type A.
On peut y voir des lignes query, forwarded, reply, etc.
On voit que chaque requête DNS est transférée à l'adresse 8.8.8.8, qui est le serveur DNS public de Google.
On remarque qu'une partie du trafic entre l'ip x.x.x.1 et le domaine m***ts.com, dont les noms de domaines de requête dns sont suspectes (encodé en base64).
En se référant à l'infrastructure réseau, on identifie que l'adresse ip est celle du routeur, ce qui nous permet d'identifier la source de l'exfiltration. On comprend donc que c'est le routeur qui est compromis, et non pas une machine du réseau local.
On obtient le premier flag, la machine source de l'exfiltration : x.x.x.1
On peut alors regarder tous les sous-domaines interrogés.
Nous obtenons le deuxième flag, m***ts.com, ainsi tous les sous-domaines utilisés par l'attaquant.
On essaye de comprendre maintenant le protocole de communication entre le routeur et le serveur DNS malveillant.
S'il n'y a pas de réponse au bout de 5 secondes ou si l'adresse IP de réponse se termine en .1, alors rien est fait.
Si l'adresse IP de réponse se termine en .2, alors le client demande l'instruction au domaine command.domain :
* Si le serveur n'envoie pas de commande, ne rien faire.
* Si le serveur envoie une commande (dans le champ TXT de la réponse), alors l'exécuter et envoyer à output.domain.
On comprend que le routeur envoie l'output de la commande en base64, découpé en plusieurs chunks, en suivant cette méthode :
* Le routeur interroge o<niemefichie>c<niemechunk>.<output_de_la_commande_base64>.output.domain.
On remarque que l'output de la commande est séparé par des points, ce qui est cohérent avec le format des noms de domaines.
Si l'adresse IP de réponse se termine en .3, alors des fichiers sont extraits du routeur et envoyés au serveur DNS malveillant, au domaine file.domain.
* Le routeur interroge o<niemefichie>c<niemechunk>.<chunk_encodé_en_base64>.file.domain.
Dans notre cas, on remarque que seul un fichier est exfiltré, et que son id est 500.
On comprend que le routeur envoie des fichiers présents sur le routeur, mais on ne sait pas exactement lesquels.
On constate que les contenus sont en base64, donc facilement décodables.
Pour la commande, un simple décodage identifie le contenu envoyé.
Pour l'output de la commande, on voit que le résultat est séparé en plusieurs chunks, eux-mêmes séparés par des points.
On peut donc reconstituer l'output complet en concaténant les chunks dans l'ordre, puis en enlevant les points, puis en décodant le tout en base64.
Pour le fichier exfiltré, on applique la même méthode que pour l'output de la commande.
On constate que l'output ressemble encore à du base64, donc on décode une nouvelle fois le tout.
On obtient un fichier binaire, qu'on peut analyser avec la commande file.
On constate que le fichier est une archive zip, qu'on peut décompresser pour obtenir le contenu final.
Le tout est automatisable avec un script python, disponible ci-dessous dans le dossier resolution/solve.py.
On obtient ainsi le résultat suivant:
Enfin, on décompresse l'archive zip pour obtenir le contenu final.
➜ 1-step_1 git:(step4) ✗ tar xzvf extracted_file.bin
facture.pdf
Enfin, en ouvrant le fichier facture.pdf, on obtient le dernier flag.
