Maintenant que nous savons comment il est entré dans le système, il faut découvrir comment il a pu s'infiltrer plus profondément. Il semblerait qu'un binaire malveillant ait été exécuté.
Votre analyse du poste RH a porté ses fruits : une macro malveillante dissimulée dans un document Word a réussi à télécharger et exécuter un fichier suspect sur le système compromis.
Le fichier en question, un binaire Windows, constitue la
prochaine étape de votre investigation. Ce programme, d'apparence anodine, cache probablement les véritables intentions de l'attaquant.
Votre mission consiste désormais à analyser cet exécutable pour comprendre son fonctionnement et découvrir les actions réalisées par l'attaquant.
Nous cherchons à savoir comment l'attaquant a pu rentrer dans le système interne de Sparklez, pourtant seulement accessible par un VPN WireGuard.
Il pourrait être intéressant de se pencher sur la configuration de celui-ci. En addition, d'autres matériels sont fournis (sites, configurations...).
Néanmoins, l'accès que l'attaquant a récupéré est bien sur la configuration VPN.
Parmi les projets présents sur le git fourni, nous trouvons :
- Le site de gestion des tickets
- Le site permettant de téléverser des clés publiques pour obtenir un accès VPN
- La configuration du VPN Wireguard
C'est ce dernier qui nous intéressera particulièrement.
À première vue, il est compliqué de savoir s'il y a, ou non, des accès illégitimes permis par le VPN.
Néanmoins, le tout est fourni sous forme d'un dépôt git. En parallèle de celui-ci, des tickets sont présents dans le projet Orya sur le git, nous donnant des indications dont des modifications apportées au VPN. Il est alors possible de cibler une configuration semblant anormale serveur pour un client, de deux manières différentes mais pouvant être complémentaires :
- En regardant que pour le ticket demandant un accès VPN pour le PDG, un deuxième accès a été octroyé, ce qui est suspect.
Il est alors attendu de faire le rapprochement entre la clé publique utilisée à ce moment-là, les tickets des DSI, et l'accès pour l'utilisateur créé après ayant la même clé publique dans la configuration VPN. Cela veut donc dire que ce nouveau profil de VPN correspond en fait à celui de l'attaquant. Le login associé est accessible en commentaire de cette configuration client.
Nous souhaitons néanmoins savoir à quel moment, après s'être vu retirer les accès VPN légitimes, l'attaquant se les ait discrètement réattribués.
Il est possible de suivre les modifications et ainsi voir quand cette modification a été portée, ainsi que le hash associé au commit apportant cette modification. On remarque aussi que l'auteur de cette modification est bien notre suspect.
