Durante la semana del 20 de febrero de 2023, el equipo MDR de Sophos X-Ops recibió dos solicitudes distintas de búsqueda de amenazas relacionadas con actividad inusual en los entornos Microsoft 365 (antes Office 365) de dos clientes. Esto provocó una investigación de conjuntos de eventos de seguridad de Microsoft Graph reenviados a Sophos XDR, para identificar si se había producido actividad sospechosa o maliciosa. Microsoft Graph gestiona el flujo de datos y el acceso a la nube de Microsoft (es decir, 365, Windows y Enterprise Mobility + Security); su API de seguridad puede conectar varios proveedores de seguridad y les permite operar de forma federada según sea necesario.
En este artículo, ofreceremos un recorrido detallado de cada paso del flujo de ataque, junto con el propósito de cada técnica de ataque y la consulta mediante la cual se identifica cada una en XDR. Sophos MDR llegó a la conclusión de que el compromiso de la cuenta de correo electrónico tuvo lugar en ambos casos, utilizando tácticas, técnicas y procedimientos (TTP) notablemente similares. Las referencias cruzadas de los datos de ambos casos mostraron que los dos ataques podrían estar relacionados con el mismo agente de amenazas (desconocido).
Ten en cuenta que las consultas y ejemplos que aparecen a continuación hacen referencia a “CompromisedAdmin@example.com”, “TargetUser@example.com”, etc. Son marcadores de posición y debes sustituirlos en tus consultas por tus propias direcciones de correo electrónico de administrador y usuario. Como medida de ofuscación, no diferenciamos en este escrito qué apariciones de “example.com” están conectadas a qué incidente de cliente.
Matriz MITRE ATT&CK de Microsoft 365
El entorno operativo de Microsoft 365 es lo suficientemente único como para que se requiera un subconjunto específico de TTP de adversarios para llevar a cabo búsquedas e investigaciones de amenazas dentro de estos entornos en la nube. La Figura 1 muestra una captura de pantalla de la Matriz ATT&CK de MITRE para Office 365. Este artículo se centrará en un subconjunto de estas TTP relevantes para el compromiso de cuentas de correo electrónico, y mostrará cómo se aprovecharon para identificar la actividad adversaria expuesta en esta doble caza de amenazas. Al final de este artículo publicamos enlaces a cada una de las tácticas y técnicas del MITRE citadas.
Acceso inicial: TA0001
En ambos casos, el compromiso inicial tuvo lugar aproximadamente 90 días antes de cualquier ejecución maliciosa observada. Es posible que este retraso fuera intencionado, para esperar a que transcurriera el periodo de registro predeterminado de 90 días para la renovación de Microsoft 365, o tal vez debido a un traspaso de un Agente de Acceso Inicial (IAB) a otro actor de la amenaza. El autor de la amenaza accedió a varias cuentas de los sistemas objetivo y, en un caso, cambió el número de teléfono asociado a una cuenta concreta por otro distinto. Examinaremos esta técnica específica en la sección Manipulación de Cuentas, más adelante.
Cuentas válidas: Cuentas en la Nube (T1078.004)
Inicio de sesión externo
Se utilizaron múltiples direcciones IP externas para iniciar sesión en cuentas, que el actor comprometió o creó tras obtener el acceso inicial por medios desconocidos (véase la sección Persistencia más adelante). Se observó que tres de estas direcciones IP eran idénticas en ambos casos.
El análisis de estas tres direcciones IP arrojó los siguientes resultados:
104.161.20[.]102
- Siete informes de abuso de IP en AbuseIPDB
- Nombre de dominio de ioflood[.]com, que es un proveedor de alojamiento de servidores dedicados
- Puertos expuestos: FTP (21/TCP), RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)
20.232.202[.]245
- Alojado en Microsoft Azure Cloud (zona este de EE.UU.)
- Puertos expuestos: RDP (3389/TCP)
185.241.149[.]122
- 25 denuncias de abuso de IP en AbuseIPDB
- Nombre de dominio de ipxo[.]com, que es un mercado de direcciones IP que alquila recursos IP
- Puertos expuestos: RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)
ioflood.com e ipxo.com, ambas empresas legítimas, fueron contactadas por MDR en relación con este abuso observado de sus servicios.
Consulta Sophos XDR
SELECT creation_time, user_id, operation, client_ip
FROM xdr_identity_o365
WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com)
AND operation IN ('UserLoggedIn', 'UserLoginFailed')
Persistencia: TA0003
Crear cuenta: Cuenta Nube (T1136.003)
Durante los primeros días del ataque, el autor de la amenaza creó una o varias cuentas en el sistema objetivo para establecer la persistencia, y luego (como ya se ha mencionado) esperó meses antes de seguir actuando.
Una de estas cuentas de nivel de administrador se creó durante la primera semana de diciembre; luego se utilizó para crear otra cuenta a finales de febrero, casi ochenta días más tarde y unos días antes de que se llamara a Sophos para que se ocupara del caso. (Los investigadores no disponían de los registros anteriores a la creación de la cuenta de administrador global).
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, object_id, modified_properties FROM xdr_identity_o365 WHERE operation LIKE 'Add user.'
Manipulación de Cuentas (T1098)
Actualizaciones de usuarios
El actor de la amenaza añadió un nuevo número de teléfono a una cuenta de usuario comprometida, probablemente para realizar e interceptar llamadas telefónicas directamente o a través de Microsoft Teams. Hay varias razones por las que el atacante podría haber hecho esto, incluyendo fines de ingeniería social, enmascaramiento o subversión de la MFA. Curiosamente, este cambio de número de teléfono se produjo casi tres semanas antes de la actividad posterior del atacante.
Operación Exchange: “Update User”.
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, client_ip, target, modified_properties FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation LIKE ‘Update user.’
Manipulación de cuentas: permisos adicionales de delegado de correo electrónico (T1098.002)
El actor de la amenaza aprovechó su cuenta privilegiada para concederse acceso total a los buzones de correo de otros usuarios. También utilizó este privilegio para “enviar como” (es decir, enviar correos electrónicos desde las cuentas de otros usuarios), lo que podría conducir a nuevos ataques a empresas con las que estos dos clientes hacen negocios. También se eliminaron correos electrónicos.
Operaciones de Exchange: ‘Add-MailboxPermission’, ‘Add-RecipientPermission’
La siguiente tabla muestra un ejemplo de modificación de permisos para el acceso total visto en esta fase.
| Usuario | Operación | object_id | acceso | nombre |
| CompromisedAdmin@eample.com | Add-MailboxPermission | TargetUser | “FullAccess” | “AccessRights” |
Figura 2: ampliación de permisos para una cuenta atacada
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, object_id, JSON_EXTRACT(parameters, ‘$[2].Value’) AS Access, JSON_EXTRACT(parameters, ‘$[2].Name’) AS Name, JSON_EXTRACT(parameters, ‘$[1].Value’) AS Source, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation LIKE ‘%Permission%’
Manipulación de Cuentas: Roles adicionales en la nube (T1098.003)
Modificaciones en SharePoint
El actor de la amenaza añadió la cuenta de administrador comprometida al SharePoint de la organización objetivo con el rol de “administrador del sitio”. Además, también habilitaron “compartir utilizando enlaces anónimos”, lo que permitió al actor crear enlaces a archivos que no requerían autenticación para acceder.
Operaciones de Exchange: ‘SiteLocksChanged’, ‘SiteCollectionCreated’, ‘SiteCollectionAdminAdded’
La siguiente tabla muestra ejemplos de roles en la nube modificados para conceder acceso completo, como se ve en esta fase:
| Usuario | Operación | Object ID | Propiedades modificadas |
|---|---|---|---|
| CompromisedAdmin@example.com | SiteLocksChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”True”,”NewValue”:”False”,”Name”: “SiteAccess”}] |
| CompromisedAdmin@example.com | SiteCollectionAdminAdded | https://sharepoint.com/<user_page> | [{“OldValue”:””,”NewValue”:”CompromisedAdmin@example.com”, “Name”:”SiteAdmin”}] |
| CompromisedAdmin@example.com | SharingPolicyChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”False”,”NewValue”:”True”,”Name”: “ShareUsingAnonymousLinks”}] |
| CompromisedAdmin@example.com | SharingPolicyChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”Disabled”,”NewValue”:”Enabled”, “Name”:”ShareUsingAnonymousLinks”}] |
Figura 3: alteración de roles para dar acceso total a la cuenta controlada por el atacante
Consulta Sophos XDR
SELECT creation_time, user_id, operation, client_ip, object_id, modified_properties FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation IN (‘SiteLocksChanged’, ‘SiteCollectionCreated’,’ SiteCollectionAdminAdded’)
Recolección: TA0009
Recolección de correo electrónico: Recolección Remota de Correo Electrónico (T1114.002)
Tras otorgarse permisos completos de los buzones de correo de otros usuarios, el actor de la amenaza procedió a leer los correos electrónicos de los usuarios para obtener más información sobre ellos y la organización. Este nivel de acceso también puede utilizarse para obtener datos personales y confidenciales relacionados con operaciones bancarias y empresariales, verificar la configuración de la AMF y mucho más, incluida la actividad relacionada con el cambio de número de teléfono mencionado en la sección Manipulación de cuentas. En este punto, se accedió a los correos electrónicos de ese usuario aproximadamente 20 días antes de esta fase, probablemente para un mayor reconocimiento dentro de la red.
El actor de la amenaza también pudo acceder, crear, responder y enviar correos electrónicos desde la cuenta de administrador comprometida, haciéndose pasar por el usuario objetivo. También es posible que el número de teléfono añadido a la cuenta mencionada en Manipulación de cuentas se utilizara para hacerse pasar por el propietario de la cuenta, tras acceder a los correos electrónicos del usuario desde otra cuenta de su propiedad.
Algunas cabeceras y creaciones de correo electrónico interesantes incluían respuestas a solicitudes de código de acceso, correos electrónicos relacionados con operaciones bancarias (como se muestra en la tabla siguiente) y respuestas a correos electrónicos de proyectos internos.
Operaciones de Exchange: “Update”, “Create”, “SendAs”.
La siguiente tabla muestra un ejemplo de la cuenta controlada por el ataque haciéndose pasar por otra cuenta, como se ve en esta fase:
| usuario | operación | mailbox_owner | asunto |
| CompromisedAdmin@example.com | SendAs | TargetUser@example.com | “Accepted: [BANK NAME REDACTED] Passcode” |
Figura 4: La cuenta controlada por el atacante se ajusta para hacerse pasar por otro usuario
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn, modified_properties, JSON_EXTRACT(item, '$.Subject') AS Subject, item
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('SendAs', 'Create', 'Update')
Recolección de correo electrónico: regla de reenvío de correo electrónico (T1114.003)
Reglas de transporte
En ambos casos, el actor de la amenaza implementó reglas de transporte o editó reglas existentes. Estas reglas de transporte siguen nombres relacionados con el bloqueo de actividades sospechosas, como “Bloquear suplantación de identidad” o “[ELIMINADO] Compromiso”.
Estas reglas se utilizaron para redirigir los correos electrónicos que contenían determinadas cabeceras relacionadas con “admin” o “OnlineBanking” al buzón del usuario comprometido.
Se añadieron otras reglas para eliminar los correos de estas reglas de transporte (Eliminación de indicadores: Borrar datos del buzón / T1070.008), de modo que el correo se redirigiera a la cuenta comprometida y se eliminara del buzón del usuario instantáneamente.
Operaciones de Exchange: “New-TransportRule”, “Set-TransportRule”, “Enable-TransportRule”.
Regla de Transporte Ejemplo 1
Esta regla permitía al actor controlar qué correos electrónicos se enviarían al buzón de un usuario objetivo abusando de la función ModerateMessageByUser de Exchange Online.
[
{ "Name": "Name",
"Value": "Block Phishing"
},
{.
"Name": "ModerateMessageByUser",
"Value": "CompromisedAdmin@example.com"
},
{
"Name": "SubjectOrBodyContainsWords",
"Value": "Exchange admin privilege;Global Administrator;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;User at risk detected;Risky sign-in;Mailbox Permission Changed;High-severity alert;[REDACTED BANKING SUBJECT LINE]"
},
{
"Name": "DeleteMessage",
"Value": "False"
}
]
Regla de transporte Ejemplo 2
Esta regla permitía al actor eliminar correos electrónicos con un asunto o cuerpo específico para evitar levantar sospechas de los administradores y usuarios de la organización objetivo.
[
{
"Name": "Name",
"Value": "Display name spoofing"
},
{
"Name":"SubjectOrBodyContainsWords"
"Value":"Exchange admin privilege;A user account has been created or modified;Suspicious Inbox Rule;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;High-severity alert;InsightIDR Incident Alert;Granted mailbox permission;New-InboxRule;CompromisedAdmin@example.com ",
},
{
"Name":"DeleteMessage"
"Value":"True",
},
{
"Name":"RedirectMessageTo"
"Value":"",
},
{
"Name":"ExceptIfFrom"
"Value":"",
},
{
"Name":"HeaderMatchesMessageHeader"
"Value":"",
},
{
"Name":"HeaderMatchesPatterns"
"Value":"",
}
]
La siguiente tabla proporciona una lista de los nombres de las reglas de transporte observadas en esta fase, con algunas redacciones para proteger la identidad del cliente.
object_id
Block Spoofing
Block Phishing
Copy of WarnAuditHigh-RiskPhishingPatterns
WarnAuditHigh-RiskPhishingPatterns
[REDACTED // BANKING]
Display name spoofing
Bypass SPAM Filter
[REDACTED] Compromise
redirect [REDACTED] email to DC
Figura 5: una selección de indicadores que apoyan la conclusión de los cazadores de que se trata de T1114.003 en acción
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, client_ip, object_id, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’) AND operation LIKE '%Transport%'
Defensa Evasión: TA0005
Deteriorar Defensas: Desactivar o Modificar Herramientas (T1562.001)
TenantAllowBlockListSpoofItems
En ambos casos, el actor de la amenaza aprovechó la función de Exchange Online “TenantAllowBlockListSpoofItems” para añadir entradas de remitentes falsos a la lista de remitentes permitidos, lo que le permitió saltarse las reglas de remitentes falsos y enviar correos electrónicos a objetivos desde dominios falsos.
En uno de los casos, el actor de la amenaza fue un paso más allá y añadió algunos dominios adicionales, así como una dirección IP, a la lista Tenant Allow/Block:
- emailsrvr[.]com
- continental-database[.]com
- “104.161.20[.]102”
Observa que la IP de esta regla se utilizó en ambos casos para acceder a las cuentas comprometidas.
Operación de intercambio: ‘New-TenantAllowBlockListSpoofItems’.
Ejemplo de TenantAllowBlockListSpoofItems
[
{
"Name": "Identity"
"Value": "default",
},
{
"Name": "SpoofType"
"Value": "External",
},
{
"Name": "Action"
"Value": "Allow",
},
{
"Name": "SpoofedUser"
"Value": "impersonated-email-account.com",
},
{
"Name": "SendingInfrastructure"
"Value": "botasso.cl",
}
]
Consulta XDR de Sophos
SELECT creation_time, user_id, operation, client_ip, object_id, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’) AND operation LIKE '%Spoof%'
Eliminación del Indicador: Borrar datos del buzón (T1070.008)
Eliminación de correos electrónicos
El borrado de correos electrónicos se utilizó como táctica en ambos casos. Algunas eliminaciones se produjeron debido a reglas de transporte que el atacante añadió (Recolección de Emails: Regla de Reenvío de Emails / T1114.003).
Los correos electrónicos eliminados pueden proporcionar contexto sobre el propósito del ataque. En uno de los casos, observamos correos electrónicos creados en relación con códigos de acceso (incluso para banca online), así como correos electrónicos eliminados que revelaban que se había restablecido un código de acceso. Se observó actividad adicional, como “bloqueos” y “restablecimiento de contraseñas”, lo que dejaba claro que el actor probablemente había comprometido la autenticación de los usuarios objetivo.
El agresor también eliminó correos electrónicos recibidos de Microsoft 365 Security, probablemente para evitar que los controles de seguridad de terceros notificaran la amenaza a la víctima.
Operaciones de Exchange: ‘MoveToDeletedItems’, ‘HardDelete’, ‘SoftDelete’.
La siguiente tabla proporciona una lista de las reglas de borrado de correo electrónico observadas en esta fase, con algunas redacciones para proteger la identidad del cliente.
| Usuario | Operación | Porpietarrio del correo | Asunto |
|---|---|---|---|
| CompromisedAdmin@example.com | MoveToDeletedItems | TargetUser@example.com | “Microsoft 365 security: You have messages in quarantine” |
| CompromisedAdmin@example.com | HardDelete | TargetUser@example.com | “Reset your Online Banking password” |
Figura 6: manipulación de las reglas para desviar correos electrónicos que podrían alertar al usuario objetivo de la presencia del atacante
Consulta Sophos XDR
SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn,
JSON_EXTRACT(affected_items, '$[0].Subject') AS Subject, affected_items
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('MoveToDeletedItems', 'HardDelete', 'SoftDelete')
Recomendaciones
Hay muchas opciones disponibles para combatir los compromisos de las cuentas de correo electrónico, como los dos comentados aquí. Tu mejor elección dependerá de las operaciones de tu empresa, el coste, el modelo de riesgo y los requisitos.
Aquí expondremos algunas sugerencias básicas. Sin embargo, recomendamos encarecidamente mecanismos de prevención y detección, adaptados a tu entorno y basados en las tácticas y técnicas detalladas en este artículo (es decir, detecciones XDR y cacerías periódicas de amenazas).
- Habilita la MFA para los usuarios con privilegios (o para todos los usuarios, si es posible).
- Realiza auditorías periódicas de las creaciones de cuentas de usuario y de las cuentas de administrador.
- Permite IP de un rango aprobado para la autenticación (por ejemplo, tu subred VPN) y bloquea los rangos no aprobados.
- Adquiere una retención de datos ampliada para tu producto XDR para mantener el registro más allá del periodo de retención predeterminado de 90 días (o considera soluciones de reenvío/registro de eventos).
Indicadores de Compromiso (IOC)
En nuestro GitHub está disponible una lista de indicadores de compromiso asociados a esta investigación.
Todas las técnicas y subtécnicas de ATT&CK comentadas anteriormente están documentadas en el sitio de MITRE. A continuación se proporcionan enlaces a cada descripción para comodidad del lector.
Agradecimientos
Imane Ismail contribuyó decisivamente a la investigación de estos casos.
Dejar un comentario