Malware Sunburst : état des lieux d’une attaque avancée et mesures de protection avec Stormshield

Le 8 décembre 2020, la société américaine FireEye publiait un communiqué de presse dans lequel elle déclarait être victime d’un malware, baptisé « Sunburst » pour l’occasion, et du vol de plusieurs outils de Red Team. Dans ce communiqué, l’entreprise de cybersécurité évoque la cyberattaque avancée d’un acteur « dont la discipline, la sécurité opérationnelle et les techniques portent à croire qu’il s’agirait d’une attaque parrainée par un État ». Déjà un évènement en soi – qui nous rappelle encore une fois qu’en cybersécurité personne n’est infaillible –, mais surtout, l’arbre qui cache la forêt.

Les éléments de contexte de l’attaque Sunburst

Quelques jours plus tard, le 13 décembre, nous apprenions l’étendue des dégâts : avec FireEye, plus de 18 000 entreprises et institutions dans le monde seraient concernées. Et en premier lieu une quarantaine d’administrations du gouvernement américain, dont le département de la sécurité intérieure et le National Nuclear Security Administration (NNSA). Leur point commun ? La présence dans leur système d’information du logiciel Orion de l’entreprise SolarWinds, qui développe des logiciels professionnels pour la gestion centralisée des réseaux, des systèmes et de toute l’infrastructure informatique. D’après les premiers éléments de l’investigation, le groupe APT29 (Cozy Bear) semble être à l’origine de cette attaque.

Le vecteur initial de l’attaque Sunburst

Le vecteur initial de l’attaque serait une compromission en profondeur de ce logiciel de supervision des systèmes d’information. Il semble que les versions d’Orion concernées remontent jusqu’à octobre 2019.

Question technique, le malware aurait été introduit dans la chaîne de développement du logiciel, et plus précisément dans celle de la dll solarwinds.orion.core.businesslayer.dll. Une dll qui a ensuite été signée par le certificat officiel SolarWinds, garantissant sa confiance. Une fois installé dans le SI cible, le binaire s’inscrit sur le site de « Beacon » du malware en appelant le domaine avsvmcloud.com et en imitant un protocole légitime de SolarWinds. Les cyber-criminels initient ensuite une communication « command and control » sur d’autres domaines/IP qui auront été échangés via la connexion initiale.

À noter qu’une simple connexion à l’URL avsvmcloud.com n’indique donc pas forcément une compromission active du SI. Il convient de vérifier qu’elle est suivie par des communications vers d’autres domaines/IP.

Les détails techniques de l’attaque Sunburst

Obfuscation

Ce malware est technologiquement très avancé et utilise différentes techniques de dissimulation telles que :

• Utilisation de Virtual Private Server pour la communication C&C, avec des IP géographiquement similaires au pays de la victime ;
• Rotation de l’IP « dernier kilomètre » sur différents points géographiques pour limiter la détection ;
• Stéganographie pour dissimuler les communications de C&C, en utilisant le protocole officiel « Orion Improvment Program » comme support ;
• Détection (et arrêt) d’exécution en environnement de type sandbox ;
• Utilisation de comptes et de token d’authentification usurpés pour les mouvements latéraux, les alertes générées par ces usurpations n’étant généralement pas suffisamment critiques pour être vues.

Persistance

Comme dans la plupart des attaques ciblées, l’un des objectifs principaux des cyber-criminels est d’obtenir une certaine persistance de l’accès au SI de la victime. C’est bien évidement le cas ici également. Plusieurs mécanismes ont été observés :

• Création de comptes à privilèges et de tokens d’authentification dans l’Active Directory Azure par exemple (accès au « Key Vault ») ;
• Ajout d’un nouveau « federation trust » sur le domaine de la victime, plus précisément d’un objet « new Active Directory Federated Service (ADFS) TrustedRealm object » comme un nouveau certificat racine ;
• Installation d’autres Trojans...

IoC

Les différents IoC (Indicator of Compromise) de l’attaque ont été publiés par FireEye et sont disponibles ici :

• Contre-mesures applicables pour détecter le malware SunBurst : github.com/fireeye/sunburst_countermeasures
• Contre-mesures applicables pour détecter l’utilisation des outils de Red Team volés à FireEye : github.com/fireeye/red_team_tool_countermeasures

Les moyens de protection Stormshield face à l’attaque Sunburst

À partir de ces IoC, nous avons développé des signatures de détection pour nos solutions de protection réseau Stormshield Network Security (SNS) et de protection des postes Stormshield Endpoint Security (SES). Ces protections, ainsi que des recommandations génériques, sont détaillées ci-dessous.

Protection avec SNS

Plusieurs axes de protection sont activables sur SNS :

• La base antivirus intégrée à SNS, de base ou en option, doit être mise à jour afin d’embarquer les nouvelles signatures liées à Sunburst (fichiers Red Team FireEye, fichiers SolarWinds corrompus). Il s’agit de la version de base ClamAV 26018 et supérieur, et de la version de signature Kaspersky du 13 décembre.
• Notre option Extended Web Control intègre dans la catégorie « Malware » les URL malicieuses utilisées par Sunburst pour les communications de « command and control » et de « Beacon ». Si vous n’avez pas souscrit à cette option, vous pouvez bloquer les URL suivantes via une catégorie personnalisée :
  • avsvmcloud[.]com
  • freescanonline[.]com
  • deftsecurity[.]com
  • thedoccloud[.]com
  • websitetheme[.]com
  • highdatabase[.]com
  • incomeupdate[.]com
  • databasegalore[.]com
  • panhardware[.]com
  • zupertech[.]com
  • virtualdataserver[.]com
  • digitalcollege[.]org
• Enfin, nous avons développé nos propres signatures IPS listées ci-dessous. Ces signatures permettent de détecter l’utilisation d’outils de la RedTeam FireEye ainsi que différentes phases de l’exploitation de la vulnérabilité du logiciel Orion :
  • http:client.69
  • http:client:data.153
  • ssl:server:certificate.105
  • tcpudp:hostname.156
  • http:mix.334
  • http:mix.335
  • ssl:client:certificate.3

Protection avec SES

Nos solutions SES en version 7.2 ou SES Evolution en version 2.0 protègent déjà de l’utilisation des outils de RedTeam FireEye et des autres logiciels malveillants que les versions corrompues d’Orion auraient pu créer et exécuter, grâce aux fonctions de contrôle des processus et des ressources système.

Cependant, afin d’améliorer la détection et le traitement des incidents, nous avons intégré une base de hash correspondant à l’ensemble des fichiers actuellement connus des outils de RedTeam FireEye. Ce sont au total 103 hash qui sont intégrés dans ce package :

Fig. 1 : illustration des hash intégrés à nos solutions SES

Par ailleurs, spécifiquement sur SES Evolution, nous avons également intégré les règles nécessaires permettant de couvrir les premiers comportements suspects issus des versions corrompues du logiciel Orion.

Cela représente 19 adresses IP qui se retrouvent sous contrôle et qui correspondent aux serveurs utilisés par ces versions corrompues. Pour compléter la protection, le programme hôte d’Orion potentiellement corrompu est étroitement surveillé et ses opérations de création de fichiers à caractères malveillant lui sont refusées. De même, les processus enfants qu’il est amené à créer sont bloqués s’ils ne concernent pas d’autres programmes de la suite Orion.

Fig. 2 : illustration des adresses IP intégrées à notre solution SES Evolution

Ce package est configurable pour être utilisé en mode bloquant ou en alerte. Important : sur SES Evolution, ce jeu de règles doit être inséré avant celui de protection par défaut.

Recommandations face à l’attaque Sunburst

La première recommandation est bien évidement de patcher le logiciel Orion de SolarWinds.

Regardez ensuite si des communications ont eu lieu avec le domaine avsvmcloud.com depuis octobre 2019. Si c’est le cas, vérifiez si d’autres domaines inhabituels ont été en communication avec les systèmes hébergeant le logiciel Orion. Dans tous les cas, nous vous conseillons vivement de mener une action en profondeur d’investigation sur votre SI, en suivant les étapes ci-dessous :

• Déconnectez d’Internet les systèmes qui auraient pu être compromis ;
• Ouvrez un incident auprès des autorités compétentes (CNIL / ANSSI) ;
• Réalisez une revue des comptes à privilèges et des activités passées de ces comptes ;
• Retracez les faux positifs de sécurité de l’année passée afin de réévaluer la situation au regard des nouvelles informations disponibles liées à l’incident ;
• Tracez et suivez toute activité Internet inhabituelle et si nécessaire passez en mode « Whitelist » pour limiter les accès Internet aux domaines considérés comme sûrs ;
• Et surtout, faites-vous accompagner par des professionnels si vos équipes ne peuvent traiter l’incident.

Pour en savoir plus sur l’attaque Sunburst :

- La Security Advisory de Solarwinds : solarwinds.com/securityadvisory
- La directive du gouvernement américain : cyber.dhs.gov/ed/21-01/
- La CERT du gouvernement américain : us-cert.cisa.gov/ncas/alerts/aa20-352a
- Le communiqué de presse de FireEye : fireeye.com/blog/products-and-services/2020/12/fireeye-shares-details-of-recent-cyber-attack-actions-to-protect-community.html
- L’analyse détaillée de FireEye : fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
Les masters de détection sur GitHub : github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/AzureAADPowerShellAnomaly.yaml & github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ADFSDomainTrustMods.yaml
- La protection détaillée de l’agent Kaspersky : securelist.com/how-we-protect-against-sunburst-backdoor/99959/