La jugada del contrabandista: descubriendo el Tradecraft de adversario en el medio mediante HTML smuggling

tl;dr

Huntress descubrió la infraestructura de una campaña masiva de phishing que incluye técnicas potencialmente novedosas que combinan contrabando de HTML, iframes inyectados y robo de sesión mediante proxy transparente. Esta técnica permite a un atacante robar credenciales y evadir MFA si una víctima inicia sesión en un iframe renderizado localmente y proxificado de forma transparente del portal de inicio de sesión de Outlook. Esta técnica es novedosa para nosotros, al menos, y no hemos visto ningún ejemplo de ella antes (si tú sí, me encantaría saberlo: matt.kiely[@]huntresslabs.com). Enviamos una solicitud de eliminación a NameCheap para todos los dominios identificados. Probablemente todavía haya más por ahí. Los elementos de la matriz ATT&CK y los IoC están al final de este blog. Cuídate.

Mira a Matt Kiely hablar sobre esta técnica.

Antecedentes

El 21 de mayo de 2024, Huntress identificó tres dominios de interés a partir de nuestra telemetría de Detección y Respuesta de Amenazas de Identidad. Los tres dominios se enumeran a continuación. ¿Algo te llama la atención de inmediato?

hxxps://rnsnno.szyby[.]pro/

hxxps://rnsnno.kycmaxcapital[.]pro/

hxxps://rnsnno.2398-ns[.]pro/

Los tres URL usan el mismo subdominio y el mismo dominio de nivel superior, pero diferentes nombres de dominio. Una investigación adicional reveló que los tres dominios se habían registrado a través de NameCheap el día anterior a su descubrimiento el 21 de mayo:

Habiendo pasado tiempo detrás de la consola de proxies transparentes como red teamer, esto me hizo saltar todo tipo de alarmas. NameCheap sigue siendo uno de los registradores de dominios más prolíficos para la actividad de adversarios, emulada o no. Pero los nombres de dominio y su antigüedad por sí solos no respaldaban la hipótesis de que esto fuera realmente malicioso todavía, así que tuvimos que hacer más reconocimiento.

Al examinar la raíz web de uno de los servidores se reveló que la página de destino redirige a hxxps://example[.]com, que es una página de destino de ejemplo benigna usada para demostraciones de aplicaciones web.

Más trabajo detectivesco de nuestro intrépido líder del SOC Max Rogers y del analista de CTI `TP5` reveló varias entidades más interesantes asociadas con uno de los tres dominios sospechosos identificados (rnsnno.szyby[.]pro). Al examinar el panel de relaciones de VirusTotal para este dominio, identificamos un archivo payload HTML (sha265: 18470571777CA2628747C4F39C8DA39CA81D1686820B3927160560455A603E49) que contactaba a varios dominios al detonarse, incluyendo rnsnno.szyby[.]pro. La lista completa de dominios encontrados en este archivo payload está disponible en el apéndice.

Espera… ¿un archivo payload HTML? ¿Qué pasa con eso?

Contrabando de HTML 

El contrabando de HTML es un mecanismo de entrega de payloads probado y confiable, preferido por los actores de amenazas que buscan evadir las defensas modernas. En lugar de hacer phishing al objetivo con un ejecutable, por ejemplo, un actor de amenazas hace phishing al objetivo con un archivo HTML. Cuando la víctima abre el archivo HTML en su endpoint, el HTML y el JavaScript del archivo entregan un payload incrustado al usuario a través de su navegador web. Este payload suele estar codificado o cifrado y se reensambla dinámicamente dentro del navegador, luego se entrega al usuario como una descarga. Esto suele ser un payload de segunda etapa, un ladrón de credenciales, o algún otro tipo de malware infeccioso. Las ventajas del contrabando de HTML lo convierten en una táctica preferida, ya que permite que los payloads evadan la tecnología defensiva que bloquea por extensión de archivo.

Una señal reveladora de un payload de contrabando de HTML es la presencia de texto codificado/cifrado renderizado dinámicamente dentro del archivo HTML original. La función de JavaScript document.write() suele usarse para decodificar y renderizar HTML y JavaScript adicional de forma dinámica cuando el documento se carga en el navegador del cliente. Esto es exactamente lo que encontramos al abrir el archivo HTML de interés:

Cabe destacar lo siguiente:

  • El texto codificado en base64 en la primera llamada a document.write() configura el título del documento. No tiene nada especial, salvo que usa el carácter unicode de la O latina tachada en las dos O's de la palabra "Outlook":
<html lang="en"><title>Outløøk</title></html>

  • El bloque de texto codificado en base64 usado en la segunda llamada a document.write(), sin embargo, es un hallazgo valioso desde la perspectiva del análisis de malware (las URL han sido neutralizadas):
Loading Gist...

Entre otras actividades, este bloque de JavaScript obtiene un iframe de un servidor remoto y lo renderiza en la página. Cuando se abre este archivo HTML, el usuario ve la página de carga de Outlook seguida del portal de autenticación de Outlook:

Para recapitular: este archivo HTML se envía a la víctima mediante phishing y, una vez descargado, queda almacenado localmente en el equipo de la víctima. Cuando se abre, inicia el navegador predeterminado y muestra el HTML presente en el archivo local. Este HTML contiene varias llamadas a document.write() que decodifican e inyectan HTML y JavaScript adicionales en el document object model. Cuando este proceso termina, el usuario ve el portal de inicio de sesión de Outlook que le solicita su contraseña. Curiosamente, el campo de nombre de usuario ya está prellenado con la dirección de correo del usuario objetivo, así que solo debe ingresar su contraseña.

Pero queda la pregunta: ¿cómo se puede usar esto como arma? Una inspección más detallada reveló que el portal de autenticación de Outlook se inyecta como un iframe directamente en el navegador:

Al inspeccionar el tráfico de red cuando se renderiza el documento, se revelan varias llamadas de red. Muchas de estas llamadas de red se hacen a dominios sospechosos, pero incluyen componentes finales de URI de infraestructura legítima de Microsoft. Por ejemplo, una solicitud de red es hxxps://rnsnno.pristineitems[.]pro/owa/?login_hint=[correo electrónico del usuario objetivo], que incluye un dominio sospechoso (rnsnno.pristineitems[.]pro) pero también incluye una llamada al endpoint de OWA con un parámetro login_hint.

Otra solicitud adicional incluía la URL hxxps://rnsnno.vcsar[.]pro/?eymmdgau&qrc=[correo electrónico del objetivo codificado en base64]

Logramos obligar con éxito a la infraestructura sospechosa a generar una nueva página de inicio de sesión específica para uno de nuestros usuarios de prueba, al inyectar el nombre de usuario en el parámetro de URL ?qrc=:

Ahora sí estamos llegando a algo 🔥 Este resultado de prueba básicamente nos dio todo lo que necesitábamos. Entonces, ¿qué está pasando realmente aquí?

HTML Smuggling + Adversary in the Middle = 😈

Hay más que descubrir sobre el payload de HTML smuggling, pero nuestro análisis inicial fue más que suficiente para plantear una hipótesis firme:

  • El payload HTML inyecta un iframe del portal de autenticación legítimo de Microsoft, que es lo que el usuario ve al abrir el archivo HTML.
  • Sin embargo, está inyectando el iframe de la página del portal de inicio de sesión obteniéndolo desde infraestructura controlada por el enemigo.
  • Como el portal de inicio de sesión está decorado con el CSS real y la marca de una empresa objetivo, nuestra hipótesis es que esto no es un simple clon del sitio. En cambio, planteamos que esta infraestructura presenta un iframe que actúa como proxy transparente de las solicitudes de inicio de sesión. Inyectar un usuario arbitrario en los parámetros de la URL del dominio sospechoso y ver la página de inicio de sesión resultante fue suficiente para probar que se trata de un proxy, no de un clon del sitio.

En otras palabras, la página de inicio de sesión que ve la víctima es la página legítima de inicio de sesión de Outlook, pero pasa por un proxy a través de infraestructura controlada por el enemigo, lo cual permite el robo de tokens de autenticación de sesión y la omisión de MFA si la víctima llegara a ingresar su nombre de usuario, contraseña y código MFA.

Nuestra hipótesis sobre el ataque real es la siguiente:

  • El atacante hace phishing a la víctima con un payload en forma de archivo HTML.
  • La víctima lo abre en su propio endpoint.
  • El payload de contrabando HTML renderiza JavaScript en el navegador del cliente, que obtiene e incrusta un iframe del portal legítimo de inicio de sesión de Outlook.
  • Este iframe actúa como proxy del tráfico de inicio de sesión a través de infraestructura controlada por el atacante.
  • La víctima inicia sesión con su nombre de usuario, contraseña y MFA, si corresponde, lo cual genera un token de autenticación de sesión que luego es robado por el adversario en medio (adversary in the middle).
  • Esto le permite al atacante iniciar sesión como ese usuario inyectando el token de autenticación robado en su propio navegador, omitiendo el requisito de MFA y autenticándose como la víctima.

Resumen: esto tiene las características de un ataque de phishing con proxy transparente de tipo adversario en medio para omitir MFA, pero usa un payload de contrabando HTML con un iframe inyectado en lugar de un simple enlace. Y eso da miedo.

Seré sincero contigo: he ejecutado campañas de equipo rojo (autorizadas y legales) que usaron contrabando HTML para instalar un beacon en un endpoint objetivo. También he ejecutado campañas que usaron proxies transparentes para robar una sesión de comunicación de un objetivo. Ambas tácticas son sorprendentemente efectivas. Pero nunca se me había ocurrido combinarlas. Honestamente, esta es una TTP brillante y quiero asegurarme de que la mayor cantidad posible de personas se enteren para que podamos eliminarla por completo.

Herramientas del adversario

Por ahora, el equipo de investigación de Huntress no tiene una confianza del 100 % sobre la herramienta real usada en esta campaña. Sin embargo, podemos descartar con confianza Evilginx, debido a las diferencias en el patrón del señuelo, el patrón de parámetros de la URL y la existencia de archivos HTML de payload con clave. Es posible que se trate de uno de los marcos más nuevos de Phishing as a Service, pero se necesita más investigación para llegar a una conclusión en un sentido u otro. Por una cuestión de tiempo, el equipo de investigación de Huntress está dejando de lado esta determinación para priorizar la difusión sobre el mecanismo real del payload y cómo funciona.

Si esta no es en realidad una técnica de phishing nueva, al menos es nueva para Huntress, lo que significa que probablemente también sea nueva para nuestros partners. Si algún investigador tiene más información sobre los detalles de esta técnica, por favor escríbeme directamente; me encantaría conocerla (matt.kiely[@]huntresslabs.com).

¿Qué está haciendo Huntress?

Hasta ahora, hemos enviado solicitudes de retiro a NameCheap con toda la infraestructura identificada. NameCheap suele ser bastante colaborativo con sus solicitudes de retiro, así que anticipamos que la infraestructura enemiga identificada será eliminada en poco tiempo. Pero vendrán más, así que estamos usando nuestra telemetría para enviar más solicitudes a medida que las encontramos.

¿Qué puedo hacer?

Los archivos HTML son extremadamente peligrosos. Si no esperabas recibir un archivo HTML de alguien por correo electrónico, ten cuidado al manejarlo y contacta a tu departamento de TI/seguridad. Nunca ingreses tus credenciales en un portal de inicio de sesión sin verificar que sea la URL y el dominio correctos que esperas (por ejemplo, login.microsoftonline.com o su equivalente).

Si sospechas que tú o alguien que conoces fue afectado por un contrabandista sigiloso, incluso si no eres cliente protegido por Huntress, escríbeme directamente (matt.kiely[@]huntresslabs.com). Tememos que esto sea mucho más extendido de lo que hemos observado hasta ahora, y cualquier información nos ayudará a combatir este nuevo Tradecraft de identidad.

Ni siquiera estábamos buscando esto específicamente y terminamos encontrando un tipo de ataque de identidad potencialmente novedoso. ¿Te interesa conocer todas las cosas turbias que detectamos mientras cuidamos de ti? ¡Siéntete libre de iniciar una prueba con nosotros!

Apéndice

ATT&CK

TácticaTécnicaDescripción
Archivos o información ofuscadosHTML SmugglingLos adversarios usan HTML smuggling para presentar a las víctimas un portal de inicio de sesión proxyficado.
N/ARobo de cookie de sesión webLos adversarios inyectan portales de inicio de sesión renderizados en iframes que enrutan las autenticaciones a través de proxies transparentes para robar sesiones.
Adversario en el medioN/ALos adversarios usan iframes inyectados para renderizar portales de inicio de sesión que enrutan las autenticaciones a través de proxies transparentes para robar sesiones.

Indicadores de compromiso

Tipo de IoCIndicadorHash
Payload de HTML Smuggling[REDACTED ORG NAME] remittance 05212024.html18470571777CA2628747C4F39C8DA39CA81D1686820B3927160560455A603E49
Infraestructura de AitM/phishinghxxps://rnsnno.2398-ns[.]pro/N/A
Infraestructura de AitM/phishinghxxps://rnsnno.kycmaxcapital[.]pro/N/A
Infraestructura de AitM/phishinghxxps://rnsnno.szyby[.]pro/N/A

Dominios adicionales

Nota: no se confirma que todos estos dominios sean maliciosos, y muchos son servicios legítimos. Estos dominios listados se encontraron en el payload de HTML smuggling y se presentan como contexto y para coincidencia de cadenas.

AMS-efz.ms-acdc.office[.]com

aadcdn.msauth[.]net

aadcdn.msftauth[.]net

aadcdn.msftauthimages[.]net

autologon.microsoftazuread-sso[.]com

bovdrrqkblhbfk[.]local

clientservices.googleapis[.]com

content-autofill.googleapis[.]com

cs1100.wpc.omegacdn[.]net

edgedl.me.gvt1[.]com

identity.nel.measure.office[.]net

ihscshtfplb[.]local

login.live[.]com

ooc-g2.tm-4.office[.]com

outlook.ms-acdc.office[.]com

outlook.office365[.]com

part-0039.t-0009.t-msedge[.]net

passwordreset.microsoftonline[.]com

r3.i.lencr[.]org

r4.res.office365[.]com

rnsnno.szyby[.]pro

rnsnno.vcsar[.]pro

scxgcytrl[.]local

shed.dual-low.part-0039.t-0009.t-msedge[.]net

tse1.mm.bing[.]net

x1.i.lencr[.]org

Mira a Matt Kiely hablar sobre este Tradecraft.

Un agradecimiento especial a Max Rogers y `TP5` por su extraordinario trabajo detectivesco y sus contribuciones.

También te podría interesar