boku7/azureoutlookc2Azure Outlook Command & Control (C2) - Contrôler à distance un périphérique Windows compromis depuis votre boîte aux lettres Outlook. Outil d'émulation de menaces pour les APT nord-coréens InkySquid / ScarCruft / APT37. TTP : Utiliser l'API Microsoft Graph pour les opérations C2.
Azure Outlook Command & Control qui utilise Microsoft Graph API pour les communications C2 et l'exfiltration de données.
Contrôlez à distance un appareil Windows compromis depuis votre boîte aux lettres Outlook.
Elastic Security Labs a découvert des intrusions actives dans la nature utilisant SIESTAGRAPH. SIESTAGRAPH interagit avec Microsoft GraphAPI pour le commandement et le contrôle via Outlook et OneDrive. Consultez leurs excellents blogs d'analyse de malware sur les communications Azure Outlook C2 ci-dessous.
Si vous avez des informations sur des projets similaires, des informations CTI sur cette TTP utilisée dans la nature par des groupes APT/ransomware, des conseils de défense, des recommandations pour les Red Teamers intéressés par l'émulation de menace C2 Azure, ou toute autre information qui serait un bon ajout à ce blog/readme, veuillez me contacter ou soumettre une Pull Request. Merci !
Ce projet consiste en un implant qui envoie des signaux vers une boîte aux lettres Azure Outlook contrôlée par l'attaquant, qui sert de serveur de commande et contrôle (C2) ; contrôlant ainsi à distance l'appareil compromis. Un jeton d'actualisation Azure (Refresh Token) pour la boîte C2 de l'attaquant est codé en dur dans l'implant lors de la compilation. Lorsqu'il est exécuté sur un appareil Windows, l'implant accède à la boîte aux lettres Brouillons de l'attaquant via l'API Microsoft Graph. L'implant lit les instructions de commande dans la boîte aux lettres Brouillons de l'attaquant, exécute les instructions localement sur l'appareil Windows compromis et renvoie la sortie de la commande à l'attaquant via la création de nouveaux messages brouillons. L'implant répète ce comportement de contrôle à distance depuis la boîte aux lettres de l'attaquant jusqu'à ce que le processus hôte de l'implant soit quitté.
J'ai récemment commencé le Red Teaming il y a environ six mois au sein de l'équipe SpiderLabs Red Team chez Trustwave. Lors d'un engagement, j'ai eu l'honneur de travailler avec le légendaire Stephan Borosh (rvrsh3ll|@424f424f). Steve et Matt Kingstone m'ont tout appris sur l'Azure Domain Fronting, et j'ai été époustouflé de voir que le trafic Command & Control pouvait être exfiltré via HTTPS en utilisant des domaines légitimes comme ajax.microsoft.com. Il utilise même les certificats TLS de Microsoft ! Malheureusement pour moi, j'ai commencé le Red Teaming au moment où le Domain Fronting est mort sur Azure. Même si le Domain Fronting sur Azure était mort, il y avait encore beaucoup de techniques Red Team géniales à faire avec Azure.
Steve m'a présenté l'Azure Device Code Phishing. Pendant cette période, je me suis plongé dans Azure et l'API Microsoft Graph pour le Red Teaming. Nous avons créé l'outil TokenTactics, dérivé du superbe travail de Dr. Nestori Syynimaa (@DrAzureAD), et nous avons rédigé le blog The Art of the Device Code Phish si vous êtes intéressé par notre méthodologie.
Lors de la création de TokenTactics et de l'expérimentation avec l'API MS Graph, j'ai découvert qu'il était possible d'utiliser l'API Microsoft Graph comme canal C2. Il existe de nombreuses façons différentes d'utiliser l'API Microsoft Graph comme canal C2, et je ne suis pas la seule personne (ni la première) à l'avoir découvert. VX-Underground, créé par @smelly__vx - le créateur/éditeur de la technique HellsGate, a publié le mois dernier que le groupe nord-coréen Advanced Persistent Threat (APT) "InkySquid" (alias ScarCruft et APT37) utilise l'API Microsoft Graph pour les opérations C2. Après avoir publié un teaser de ce projet sur Twitter et LinkedIn, plusieurs professionnels DFIR ont commenté que cette technique d'utilisation de l'API Microsoft Graph pour les opérations C2 est activement utilisée par des groupes de ransomwares dans la nature, depuis des mois.
Pendant l'engagement Red Team, j'ai essayé de faire fonctionner Cobalt Strike avec l'API Microsoft Graph comme canal C2. Malheureusement, j'ai échoué, mais c'est toujours un objectif futur. Le problème que je rencontre pour que cela fonctionne avec Cobalt Strike, est que l'API Microsoft Graph utilise deux jetons pour les communications. Le premier jeton est le Refresh Token qui peut durer jusqu'à 90 jours. Le second jeton, l'Access Token, est un jeton temporaire qui dure environ une heure. Les communications directes avec l'API Microsoft Graph se font en s'authentifiant avec l'Access Token. Une fois qu'un Access Token expire, le Refresh Token peut être utilisé pour obtenir de nouveaux Access Tokens. Comme je suis encore novice en Red Teaming et en développement Cobalt Strike, je n'ai pas pu comprendre comment utiliser le profil Malleable C2 de Cobalt Strike pour prendre en charge l'obtention constante de nouveaux Access Tokens et l'envoi de ces Access Tokens changeants dans l'en-tête Authorization des requêtes HTTPS du beacon. Depuis la publication du teaser sur Twitter, Joe Vest, Alfie Champion et d'autres rockstars de la communauté m'ont donné une direction épique sur la façon de faire fonctionner cela avec Cobalt Strike ! Espérons qu'il y aura un suivi Cobalt Strike à ce projet à l'avenir ;)
