boku7/azureoutlookc2Azure Outlook Command & Control (C2) - Controlar remotamente un dispositivo Windows comprometido desde tu buzón de Outlook. Herramienta de emulación de amenazas para el APT norcoreano InkySquid / ScarCruft / APT37. TTP: Usar Microsoft Graph API para operaciones C2.
Azure Outlook Comando y Control que utiliza Microsoft Graph API para comunicaciones C2 y exfiltración de datos.
Controla de forma remota un dispositivo Windows comprometido desde tu buzón de Outlook.
Elastic Security Labs ha descubierto intrusiones activas en el mundo real que utilizan SIESTAGRAPH. SIESTAGRAPH interactúa con GraphAPI de Microsoft para el comando y control usando Outlook y OneDrive. Echa un vistazo a sus increíbles blogs de análisis de malware sobre comunicaciones Azure Outlook C2 a continuación.
Si tienes alguna información sobre proyectos similares, información CTI sobre esta TTP siendo utilizada en el mundo real por APT/grupos de ransomware, consejos de defensa, recomendaciones para Red Teamers interesados en la emulación de amenazas Azure C2, o cualquier otra información que sea un buen complemento para este blog/readme, por favor contáctame o envía un Pull Request. ¡Gracias!
Este proyecto consiste en un implante que se comunica con un buzón de Outlook Azure controlado por el atacante, que actúa como el Comando y Control (C2); controlando de forma remota el dispositivo comprometido. Un Token de Actualización de Azure para el buzón C2 del atacante está codificado directamente en el implante durante la compilación. Cuando se ejecuta en un dispositivo Windows, el implante accede al buzón de Borradores del atacante a través de Microsoft Graph API. El implante lee las instrucciones de comando del buzón de Borradores del atacante, ejecuta las instrucciones localmente en el dispositivo Windows comprometido y devuelve la salida del comando al atacante mediante la creación de nuevos mensajes de Borrador. El implante repite este comportamiento de ser controlado de forma remota desde el buzón del atacante hasta que se cierra el proceso anfitrión del implante.
Recientemente comencé en Red Team hace aproximadamente medio año en el SpiderLabs Red Team de Trustwave. Durante un engagement tuve el honor de trabajar con el legendario Stephan Borosh (rvrsh3ll|@424f424f). Steve y Matt Kingstone me enseñaron todo sobre Azure Domain Fronting, y me sorprendió que el tráfico de Comando y Control pudiera ser exfiltrado vía HTTPS utilizando dominios legítimos como ajax.microsoft.com. ¡Incluso utiliza los Certificados TLS de Microsoft! Desafortunadamente para mí, comencé en Red Team al mismo tiempo que Domain Fronting murió en Azure. Aunque Domain Fronting en Azure había muerto, todavía había muchas técnicas increíbles de Red Team que se podían hacer con Azure.
Steve me presentó a Azure Device Code Phishing. Durante este tiempo me sumergí profundamente en Azure y Microsoft Graph API para Red Team. Creamos la herramienta TokenTactics, derivada del gran trabajo de Dr. Nestori Syynimaa (@DrAzureAD), e hicimos el blog The Art of the Device Code Phish si estás interesado en nuestra metodología.
Mientras creaba TokenTactics y experimentaba con MS Graph API, descubrí que era posible usar Microsoft Graph API como un canal C2. Hay muchas formas diferentes de usar MS Graph API como canal C2, y no soy la única persona (ni la primera) en descubrir esto. VX-Underground, creado por @smelly__vx - el creador/publicador de la técnica HellsGate, publicó información el mes pasado de que el grupo de Amenaza Persistente Avanzada (APT) norcoreano "InkySquid" (también conocido como ScarCruft y APT37) utiliza Microsoft Graph API para operaciones C2. Después de publicar un adelanto de este proyecto en Twitter y LinkedIn, varios profesionales de DFIR comentaron que esta técnica de usar Microsoft Graph API para operaciones C2 está siendo utilizada activamente por grupos de ransomware en el mundo real, con varios meses de antigüedad.
Durante el engagement de Red Team, intenté hacer funcionar Cobalt Strike con MS Graph API como canal C2. Desafortunadamente, fallé, pero este sigue siendo un objetivo futuro. El problema que enfrento para que esto funcione con Cobalt Strike es que MS Graph API utiliza 2 tokens para las comunicaciones. El primer token es el Token de Actualización que puede durar hasta 90 días. El segundo token, el Token de Acceso, es un token temporal que dura aproximadamente una hora. Las comunicaciones directas a MS Graph API se realizan autenticándose con el Token de Acceso. Una vez que un Token de Acceso expira, el Token de Actualización se puede usar para obtener nuevos Tokens de Acceso. Como todavía soy nuevo en Red Team y desarrollo de Cobalt Strike, no pude descubrir cómo usar el perfil Malleable C2 de Cobalt Strike para soportar la obtención constante de nuevos Tokens de Acceso y el envío de estos Tokens de Acceso cambiantes en el encabezado Authorization de las solicitudes del beacon HTTPS. Desde que publiqué el adelanto en Twitter, Joe Vest, Alfie Champion y otras estrellas de la comunidad me han dado una dirección épica sobre cómo hacer que esto funcione con Cobalt Strike. ¡Con suerte habrá un seguimiento de Cobalt Strike para este proyecto en el futuro ;)
