Il y a un an, RSA était victime d'un APT. Etat des lieux.

Il y a un an, la compagnie RSA annonçait qu'une partie de son infrastructure était sous le contrôle d'attaquants via une attaque de type APT (Advanced Persistent Threat). Le post de blog très technique de RSA (voir la 2e partie du message "anatomy of an attack") indiquait un spear phishing  associé à un 0day, puis un RAT qui a permis à un attaquant de se déplacer latéralement dans le réseau extrêmement rapidement avant d'exfiltrer les données. L'attaque a été rapide car RSA avait détecté la brèche, mais n'a malgré tout pas pu éviter le vol de données.

La compagnie command five a produit un rapport sur les canaux de communication utilisés par des APT d'un groupe de pirate qui utilise les mêmes systèmes et serveurs de commandes et contrôles. Parmi les compagnies citées nous retrouvons RSA. Le rapport confirme effectivement le post de blog à quelques détails près (apparemment le RAT pour RSA n'était pas poison ivy, mais murcy). Ce rapport permet d'éclairer certains points très intéressants sur le mode de fonctionnement et sur la détection des APT.

1/ L'installation du RAT
Rien de bien nouveau, nous retrouvons dans les cas exposés un RAT qui s'installe via du spear phishing et éventuellement un certificat valide volé dans certain cas. Les RAT n'ont rien de spécialement avancé puisque ce sont des outils que l'on trouve sur internet, certains d'entre eux existant en version commerciale (!) : X-shell par exemple ou Poison Ivy.

2/ Le contrôle des machines
Pour contrôler les machines, les ports et protocoles classiques sont utilisés: DNS puis du HTTP ou HTTPs. Les machines se connectent régulièrement sur les serveurs C&C et envoient de l'information.
Rien de très avancé non plus, depuis les réseaux RFC1918 il est plus simple à une machine d'un LAN de se connecter sur une machine à IP publique que l'inverse.

Certains noms de domaine sont choisis pour ressembler à des domaines connus, comme
*.windowupdate.com (il manque le 's' à windows) ou *.alyac.org (alyac est un outil de sécurité) afin de leurrer l'oeil non exercé d'un administrateur vérifiant ses logs.

Les protocoles sont basés sur du HTTP, c'est du GET ou du POST normal avec des données, ce qui signifie qu'un firewall ou un proxy applicatif laissera passer ces données.

3/ Comportement et détection de ces RAT
Commençons par le mauvais côté, celui ou il est difficile de se défendre.

• Révocation de certificats: Comme l'indique le rapport, certains certificats n'ont pas été révoqués pour ne pas pénaliser l'usage d'outils légitimes étant signés par celui-ci (!)
• Analyse antivirale: Bien qu'utilisant un nombre réduit de RAT, les attaquants n'hésitent pas à les recompiler, cela ayant comme effet de bord de rendre toute détection antivirale basée sur un hash du binaire inefficace (l'auteur du rapport conseille de faire un hash de certaines parties, le .rdata .text etc.. car elles sont souvent identiques).

Le bon côté c'est qu'il existe des moyens de détecter ces APT en raison de leur comportement. Ils existe deux types de défense à ces APT, tout d'abord celles qui existent déjà et dont les entreprises sont coupables de ne pas les avoir mises en oeuvre, et les défenses qui n'existent pas encore mais qui devraient être développées.

Défenses possibles:

• Les RAT appellent fréquemment leur serveur de C&C. Dans certains cas, le RAT appelle son C&C toutes les 8 seconds, ce qui représente +10000 appels par jour. Ce volume de connexions devrait être immédiatement détecté comme suspect et analysé.
• Certains RAT n'utilisent pas les DNS locaux, mais au contraire des serveurs DNS sur internet. Une politique de sécurité sur le firewall devrait empêcher ces résolutions d'être faites et alerter l'administrateur.
• Les auteurs de l'attaque continuent à utiliser des noms de domaines pour leurs C&C, même une fois que ces domaines sont blacklistés dans diverses listes. Bloquer ces listes apparaît donc comme un premier pas essentiel, mais surveiller les machines tentant de s'y connecter permet d'augmenter les chances de détection de malware.

 Défenses à créer:

• Les RAT appellent leur serveur de C&C à fréquence fixe, c'est à dire à intervalle régulier. Existe-t'il au monde une sonde IDPS qui sait indiquer les connexions régulières? Ce serait un des meilleurs moyens je pense de trouver des flux malveillants[1].
• Pour contourner les systèmes de blacklist DNS, certains RAT utilisent directement les IP pour joindre leur C&C. Existe t'il un mécanisme de suivi de connexion qui soit capable d'indiquer si une connexion vers une IP a été précédée d'une requête DNS? Cela serait également un mécanisme de surveillance efficace.

4/ Conclusion
EDIT: Pour résumer, nous pouvons considérer que l'entrée d'un attaquant dans un réseau est difficile à bloquer: spear phishing évolué, 0day (et inefficacité des certificats). Par contre, l'auteur de l'APT va chercher par la suite à se déplacer latéralement dans le réseau visé. C'est sans doute là qu'il est le plus vulnérable, du fait de ses fréquents allers-retours entre le C&C et les machins vulnérables.
Nous verrons peut-être un jour des malwares se déplacer à la manière de drone absolu sans aucun contact avec l'extérieur si ce n'est l'exfiltration des données finale. Ceux-là seront particulièrement difficile à bloquer. Mais un malware pourra t'il embarquer suffisamment d'intelligence?

[1] C'est d'ailleurs un problème mathématique amusant: Soit une distribution de noms associés à leur heure de résolution ['nom',heure]. Comment détecter dans cette distribution des évènements répétitifs?