On parle de 146.0.228.66, c’est l’adresse IP mentionnée dans la dernière ligne de l’échange avec le C2 déchiffré
à l’étape 3. On fait quelque recherche Google, et cette IP est effectivement citée comme IOC dans les rapports des
compromission Ivanti. Par exemple, sur ce site en russe, qui la lie à
UNC5221. C’est confirmé dans ce billet de Mandiant.
Ça, c’est la partie facile. La deuxième partie du flag a laissé beaucoup de gens perplexes. Qu’est-ce qu’une interface de gestion ? Un nom de service ? Je ne vous cache pas que j’ai crâmé quelques tentatives (heureusement le nombre d’essais est généreux sur les forensics..). Mais voici la bonne réponse.
J’ai d’abord tenté des bases de données de passive DNS pour déterminer à qui était attribuée l’IP à l’époque de l’attaque. Le résultat le plus intéressant est celui fournit par whoisxml :
Le premier domaine attire l’œil. En effet, areekaweb.com est aussi un IOC dans le rapport de Mandiant, et il était relié à cette adresse IP à l’époque.
En creusant ce domaine, on peut retrouver les différents enregistrements DNS reliés, via dnsdumpster :
On a deux FQDN liés à cette IP : blog et cms.areekaweb.com. On peut alors creuser un peu plus loin, par ex. sur l’Internet Archive. On peut aussi les requêter, car depuis l’attaque, les adresses IP ont changé (on peut supposer que les serveurs sous areekaweb.com ont été redéployé).
Ce qui m’a attiré l’œil (apès plusieurs essais de validation sans succès, quand même…), c’est les headers de retour sur cms.areekaweb.com :
$ curl -v https://cms.areekaweb.com/Account/Login?returnUrl=/
[...]
< HTTP/2 200
< cache-control: private
< content-type: text/html; charset=utf-8
< server: Microsoft-IIS/10.0
< x-aspnetmvc-version: 5.2
< x-frame-options: SAMEORIGIN
< set-cookie: __RequestVerificationToken=yzaV-NkYnaxUGkS1cM4v4kHTwcrDIDbZgbkaGocyvrTLKNt4_7HjZUJiPdVOPvjDPYspZwFa87bgKdJUXVbapifxok1wNMbzHtcd19_KV_81; path=/; HttpOnly
< x-powered-by-plesk: PleskWin
< x-frame-options: SAMEORIGIN
< x-content-type: nosniff
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< access-control-allow-headers: Content-Type
< access-control-allow-methods: GET,POST
< access-control-allow-credentials: true
* Illegal STS header skipped
< strict-transport-security: 1; mode=max-age=31536000; includeSubDomains; preload
< date: Mon, 08 Apr 2024 20:27:52 GMT
< content-length: 3525
Ce simple header x-powered-by-plesk, pourrait-il être la réponse ? Bien sûr, mais
c’est facile à dire après coup. D’ailleurs, en rédigeant cette solution, je me rends
compte que dnsdumpster, encore lui, donnait cette réponse avec l’IP 146.0.228.66
(quoique sans donner de dates, donc difficile de le prendre pour argent comptant):
Voilà, le flag est donc FCSC{UNC5221:plesk}.