Qbot : quelques pistes pour détecter ce trojan qui fait tout pour ne pas l’être
Les attaquants derrière le cheval de Troie Qbot sont depuis longtemps maîtres dans l’art de rester discrets. Si l’entrée en matière semble toujours rester la même, les chemins de compromissions divergent et complexifient la détection en amont de l’infection.
Phase 1 : les courriels utilisés, reprenant souvent une conversation entre un correspondant et sa (ou ses) victime(s), passent souvent à travers les mailles du filet des solutions « anti spam », mais pourquoi ?
- Les messages sont envoyés en petites quantités
- Ils contiennent des liens de téléchargement malveillants plutôt que des pièces jointes
- Les liens pointent vers des sites web légitimes mais piratés et sur lesquels les attaquants ont déposé leurs fichiers malveillants
- Les liens sont donc considérés comme « jetables » et ne restent actifs que très peu de temps
Exemple de courriel
Phase 2 : les fichiers malveillants varient beaucoup également :
- Fichiers Excel et Word avec des macros
- Fichiers OneNote avec un script caché derrière une image sur laquelle la victime est invitée à cliquer
- Fichiers au format image ISO avec un fichier de type javascript
- Fichier javascript que l’on retrouve aussi parfois dans une archive ZIP
- Exécutable Windows
- Package d’installation au format MSI
- Et plus récemment, des fichiers PDF avec un lien, vers un autre site légitime compromis, permettant de télécharger, une archive ZIP dans laquelle se trouve un javascript
Cette liste est sûrement non exhaustive, mais recense divers exemples que j’ai pu observer.
Exemple de PDF récent
Exemple de JavaScript téléchargé via PDF
Phase 3 : après « le clic »
Une fois le javascript exécuté, Powershell est utilisé pour aller télécharger une DLL malveillante et l’exécuter à son tour. C’est après que le code malveillant permettant d’initier la connexion aux serveurs de commande et de contrôle via un processus de type Windows Problem Reporting (wermgr.exe).
Dans certains scripts, curl semble être utilisé, et dans le cas des exécutables l’étape de téléchargement via le processus Powershell n’existe pas, on passe directement à l’étape de connexion au serveur de commande et de contrôle via wermgr.exe. Les scripts changent régulièrement, via un même lien ils peuvent avoir un nom aléatoire à chaque téléchargement, les serveurs de commande et de contrôle (C2) restent actifs assez peu de temps eux aussi, ce qui fait qu’une détection par signature reste incomplète, tout comme une détection réseau basée sur des adresses IP.
Détection :
Sur le système compromis, il est possible de détecter que du code est injecté dans le processus wermgr.exe. Dans cet exemple, à l’aide de PE-Sieve embarqué dans Loki1 de Florian Roth :
Avec une solution de type EDR (libre ou commerciale), il sera possible, avec l’aide de la règle Yara proposée par Felix Bilstein sur Malpedia2 (à condition que la solution utilisée permette son import) de détecter le code de Qbot injecté la processus wermgr.exe.
Exemple ici dans une analyse post-mortem à l’aide de Volatility3 et de cette règle :
Sur le réseau, là aussi, il sera assez facile de détecter les flux malveillants à l’aide d’une solution basée sur le moteur Suricata4 et les règles de détection que je partage via le projet PAW Patrules5. J’ai utilisé ici la solution communautaire SELKS proposée par Stamus Network6.
L’étape de téléchargement de la DLL via Powershell peut être facilement observée, aussi bien lorsque le téléchargement s’effectue en HTTP sans chiffrement (ou si le flux est déchiffré), à l’aide d’une règle permettant de détecter le « user-agent » Powershell qui se connecte à une adresse IP publique, ou grâce à l’empreinte JA3 Powershell lors de l’établissement d’une connexion HTTPS à une adresse IP publique :
La seconde étape, la connexion au serveur de commande et de contrôle peut, elle aussi, être détectée de plusieurs façons. Les connexions TLS sont établies directement via le socket TCP/IP de Windows 10, à destination d’adresses IP publiques, et ses empreintes JA3 aussi en TLSv1 qu’en TLSv1.2 sont très facilement identifiables. Les certificats auto-signés, sont générés de façon assez similaire, on retrouve des noms de domaine (avec des TLD différents) dans le CN du champ « issuer ». À l’aide de quelques règles créées à partir des certificats présentés par bons nombres de C2 Qbot, des alertes apparaissent là aussi. On constate même en bonus des « pattern » identiques à ceux de serveurs Emotet lors des connexions TLS établies via le socket Windows 10.
Malgré ses tentatives pour tenter de rester discret, il ne sera pas possible d’être invisible et de faire mentir les traces réseau. Maintenant, c’est à vous de l’attraper !
1 https://github.com/Neo23x0/Loki
2 https://malpedia.caad.fkie.fraunhofer.de/details/win.qakbot
3 http://volatilityfoundation.org/
4 https://suricata.io/
5 https://pawpatrules.fr/
6 https://www.stamus-networks.com/selks