Par Bhabesh Raj Rai, Associate Security Analytics Engineer

Le mardi 8 décembre, FireEye a révélé qu’il avait été compromis par un groupe de type État-nation très sophistiqué, à priori d’origine russe, et qui utilisait de nouvelles techniques pour exfiltrer les outils de sa red team. Le piratage de FireEye est désormais considéré comme le plus grand vol connu d’outils de cybersécurité depuis le piratage de la NSA par ShadowBrokers.

Le FBI a confirmé que l’intrusion avait été l’œuvre d’un État-nation mais a refusé de commenter davantage. FireEye n’a pas révélé l’étendue de l’intrusion et donc, pour l’instant, les experts ne peuvent que spéculer sur les dégâts véritablement causés. De nombreux membres de la communauté infosec ont exprimé leur opinion sur le piratage de FireEye et ont lancé diverses théories, telles que celle qui estime que les outils de la red team ainsi que les données des clients n’ont pas été volés, mais plutôt des données de renseignement confidentielles sur des groupes malveillants de haut niveau.

Les cyber-outils offensifs aux mains de groupes malveillants peuvent avoir de graves répercussions. L’utilisation d’outils informatiques offensifs volés perturbe le processus d’identification et permet aux groupes de type État-nation de masquer leurs origines.

Cependant, FireEye a précisé que les outils de la red team volés ne contenaient pas d’exploits zero-day et ne contenaient pas non plus de méthodes bien connues et documentées utilisées par les red teams dans le monde entier. Même si FireEye a déclaré ne pas croire que le vol améliorera considérablement les capacités offensives globales de l’attaquant, il s’est efforcé de mettre en place des contre-mesures pour protéger ses clients et la communauté infosec au sens large. Pour permettre aux entreprises de détecter l’utilisation d’outils volés lors du piratage de FireEye, l’entreprise a publié des contre-mesures consistant en des centaines de signatures pour des technologies facilement disponibles comme OpenIOC, Yara, Snort et ClamAV.

Les clients LogPoint peuvent utiliser les règles Snort publiées pour détecter si les outils offensifs sont utilisés contre eux.

(norm_id=Snort OR norm_id=SuricataIDS) message IN FEYE_RED_TOOLS_SIGS

Le chercheur en sécurité Florian Roth a publié une liste de correspondances des règles YARA de FireEye. Les clients LogPoint peuvent utiliser les hachages comme IOC pour les rechercher au niveau des événements de création de processus de Sysmon.

norm_id=WindowsSysmon label="Process" label=Create hash IN FEYE_RED_TOOLS_HASHES

Outre les endpoints, LogPoint peut corréler les hachages IoC avec d’autres sources, notamment les pare-feu et les antivirus.

hash IN FEYE_RED_TOOLS_HASHES

Si Sysmon n’est pas déployé dans l’environnement, les clients peuvent utiliser les noms de processus à la place, mais cette technique produit de nombreux faux positifs et n’est pas recommandée.

norm_id=WinServer label="Process" label=Create "process" IN FEYE_RED_TOOLS_NAMES

En effet, les clients peuvent utiliser trois listes : FEYE_RED_TOOLS_SIGS qui se compose de noms de règles de snort IoC, FEYE_RED_TOOLS_HASHES qui se compose de hachages et FEYE_RED_TOOLS_NAMES qui se compose de noms de processus.

Un piratage de grande envergure visant une entreprise de cybersécurité a de nouveau renforcé l’idée qu’aucune entreprise n’était à l’abri des menaces provenant des États-nations et ce n’est en général qu’une question de temps avant qu’une entreprise ne soit compromise. Les ressources et le temps illimités dont disposent ces groupes peuvent déjouer les défenses des entreprises, même si ces dernières sont bien protégées.

La communauté infosec attend maintenant de disposer d’une description détaillée de l’incident et ensuite, tous les défenseurs des entreprises devront se tenir prêts pour ajouter des détections pour toute nouvelle TTP utilisée par ce type de groupe malveillant.