El spam de raqueta de nieve aumenta la escala de los astutos ataques de suplantación de subdominios

February 09, 2017
Proofpoint Staff

La suplantación de subdominios es ahora un nuevo fenómeno. Durante años, los actores de amenazas han intentado utilizar los subdominios de las empresas (potencialmente sin supervisión) ya sea para aumentar la credibilidad de sus mensajes de phishing o de spam, o para sortear las verificaciones heurísticas de ISP mediante la distribución de ataques con una gran cantidad de subdominios por medio de una técnica conocida como “spam de raquetas de nieve”.

La novedad es la escala a la cual los atacantes están implementando en conjunto la suplantación de subdominios y el spam de raqueta de nieve, lo cual dificulta considerablemente la detección y mitigación. Además de la escala, la cual no tiene precedentes, también hemos observado que esas técnicas se emplean de manera sistemática y regular, en lugar de al azar. En este artículo de blog describimos uno de esos ataques a gran escala y enumeramos las prácticas recomendadas para la mitigación con DMARC (Domain-based Authentication Reporting and Conformance), que es una tecnología de elevado nivel de eficacia, pero que se debe implementar correctamente para evitar problemas involuntarios y mantenimiento que requiera mucho tiempo.

Nuevo tipo de suplantación de subdominios

Los investigadores de Proofpoint han identificado una nueva variante de la suplantación de subdominios. En lugar de dirigirse a una sola empresa a la vez y de utilizar gran cantidad de palabras, frases o caracteres variados como elementos del subdominio, esta nueva técnica toma todos los dominios remitentes de una gran cantidad de empresas y les antepone una marca establecida y de confianza. En este caso, los actores de amenazas emplearon LinkedIn.

LinkedIn dedicó años a cultivar la confianza en la participación en su comunidad de miembros, y, como resultado, enfrenta el riesgo, al igual que cualquier marca global de confianza, de que se suplante su dominio y perfil al mismo tiempo que los impostores sacan partido de esa confiada comunidad. La tabla siguiente muestra varios ejemplos de la manera en que los actores de amenazas se aprovechan de la marca LinkedIn para generar subdominios suplantados.

Dominios legítimos

 

Subdominios suplantados

ejemplo.com

LinkedIn.ejemplo.com

ejemplo.co.uk

LinkedIn.ejemplo.co.uk

ejemplo.ie

LinkedIn.ejemplo.ie

us.ejemplo.com

LinkedIn.us.ejemplo.com

uk.ejemplo.com

LinkedIn.uk.ejemplo.com

ie.ejemplo.com

LinkedIn.ie.ejemplo.com

En esta campaña, no sorprende que los mensajes de correo electrónico mismos sean mensajes de phishing que pretenden engañar a las víctimas para que proporcionen sus credenciales de LinkedIn. No obstante, debido a que los atacantes los envían por medio de subdominios de otras empresas y no por medio de los dominios de LinkedIn, LinkedIn no puede utilizar DMARC de manera tradicional para bloquear los mensajes.

La figura 1 muestra un ejemplo de ese tipo de mensajes:

Figura 1: Mensaje de phishing de ejemplo que utiliza el subdominio suplantado de LinkedIn

El vínculo de “Haga clic aquí” falso lleva al usuario a un sitio farmacéutico alojado en .ru, pero lo más probable es que anteriormente apuntaba hacia una página ficticia de LinkedIn convincente diseñada para recabar las credenciales del usuario.

Aunque esos mensajes no están diseñados para atacar específicamente a clientes o socios de ejemplo.com, están explotando sus dominios. Con el tiempo, el ataque podría dañar la reputación de la marca ante los ojos del consumidor e igual de importante para la reputación del dominio entre los proveedores de bandejas de correo de consumo es que si los usuarios ven suficientes de esos mensajes y los marcan como spam, entonces los proveedores de buzones de correo podrían penalizar los mensajes enviados desde ejemplo.com y sus subdominios.

Son muy pocas las empresas en las que no hemos observado esa práctica y parece que para casi todos los dominios es un juego parejo. Lo que se ve con ejemplo.com, .co.uk, e .ie, también se ve con acme.com, .co.uk, e .ie, y así sucesivamente.

De hecho, desde que observamos un ataque de subdominios de LinkedIn reciente, hemos visto una nueva ola de suplantaciones de subdominios más amplia y más general. Aunque en la primera instancia vimos que aparecía un subdominio LinkedIn. con cada uno de los dominios remitentes de nuestros clientes, los actores de amenazas ahora han empezado a utilizar muchas variaciones de palabras, nombres y frases a modo de subdominios.

Esto ha resultado en un aumento masivo de “dominios sugeridos” para algunos clientes, en los que hemos visto múltiples subdominios fraudulentos de cada dominio primario afectado, tal como se muestra en la figura siguiente.

Figura 2: Proliferación de suplantaciones de subdominios; en este caso hemos observado que han aparecido 5.509 subdominios en un plazo de siete días

Cómo aprovechar la herencia de DMARC para bloquear mensajes malignos

Le debemos la visibilidad de este fenómeno al principio de herencia de DMARC. Si un subdominio no cuenta con su propio registro DMARC en DNS a nivel de subdominio, cualquier mensaje que se envíe haciendo uso de ese subdominio como dirección de correo electrónico visible (encabezado de dominio remitente) heredará los atributos del registro DMARC del dominio primario.

Es decir que si LinkedIn.ejemplo.com no tiene un registro DMARC explícito, entonces heredará los atributos de DMARC (nivel de directiva y direcciones de informe) de ejemplo.com, para enviar cualquier informe relevante a las mismas direcciones de informe.

Además, si ejemplo.com utiliza la directiva p=none de DMARC debido a que no ha logrado llegar a p=reject, entonces LinkedIn.ejemplo.com, por herencia, también estará en p=none y se podrán entregar los mensajes fraudulentos enviados por medio de ese subdominio.

Los administradores también podrían agregar un registro p=reject de DMARC para cada uno de esos subdominios a medida que se informen y cuando se informen, pero se trata de un método reaccionario y sería una batalla interminable al surgir cada vez más subdominios.

_dmarc.LinkedIn.dominio    IN    TXT    v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

Es mucho más eficaz y eficiente si se utiliza el principio de herencia para permitir que los propietarios de los dominios afectados bloqueen esos mensajes. No obstante, esa técnica todavía necesita tomarse con precaución, debido a que lo que hereden los subdominios fraudulentos sin registros DMARC también lo heredarán los subdominios que esas organizaciones utilicen de forma legítima. Se recomienda lo siguiente a las organizaciones que implementen DMARC:

Paso 1: Preparar todos los subdominios

El primer paso consiste en asegurarse de que todos los subdominios legítimos estén listos para heredar la directiva de rechazo, o bien, de que tengan sus propios registros DMARC explícitos a fin de prevenir la herencia involuntaria.

_dmarc.subdominio    IN    TXT    v=DMARC1; p=none; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

Paso 2: Considerar los dominios primarios

A continuación, se deben considerar los dominios primarios relevantes (o todos). Si se encuentran listos para pasar a una directiva de rechazo de DMARC, todos los posibles subdominios que se encuentren debajo de los dominios primarios y que no tengan su propio registro DMARC heredarán la misma directiva de rechazo.

_dmarc.dominio    IN    TXT    v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

Paso 3: Agregar las etiquetas necesarias

Si los dominios primarios no están listos para el rechazo, las organizaciones todavía pueden utilizar la herencia agregando la etiqueta sp=reject específica del subdominio al registro DMARC del dominio primario. Esa etiqueta permite que las organizaciones mantengan los dominios primarios en cualquier directiva que sea apropiada, al mismo tiempo que completen cualquier tarea de gobernanza del correo electrónico. Al mismo tiempo, se instruye a todos los ISP y a los destinatarios de correo electrónico que todo subdominio que no tenga su propio DMARC se tratará como si estuviera en rechazo.

_dmarc.dominio    IN    TXT    v=DMARC1; p=none; sp=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

Se debe evitar la herencia involuntaria

Nuevamente, el riesgo de herencia involuntaria es real, por lo que estos pasos se deben seguir con cautela, pero si las organizaciones logran implementar esto adecuadamente, no solamente podrán bloquear este ataque de suplantación de subdominios LinkedIn., sino que bloquearán un panorama de amenazas mucho más amplio. TODO subdominio será tratado del mismo modo en consecuencia.

A modo de referencia, el caso mostrado en la figura 2 también se mitigó del mismo modo; la solución es la misma independientemente del formato del subdominio fraudulento. En el caso de este cliente en particular, los 5.509 subdominios vistos en un plazo de siete días se podían sintetizar en solamente 41 dominios primarios. Ya hemos abordado la suplantación de subdominios (haciendo uso de los métodos mencionados) en 26 de ellos, lo que significa que solamente es necesario hacer 15 cambios sencillos en DMARC para asegurarse de que no sea posible ninguna otra suplantación de subdominios.

Una vez más, era imperativo realizar una verificación de diligencia debida para garantizar que ningún subdominio legítimo heredara de forma involuntaria alguna instrucción de rechazo de manera prematura.  

Conclusión

La suplantación de subdominios y el spam de raqueta de nieve van de la mano. No obstante, los atacantes están aumentando el nivel en términos de escala. Aunque la comunidad de seguridad prestó particular atención al phishing relacionado con LinkedIn informado la semana pasada, esta técnica puede afectar virtualmente a cualquier empresa y sacar provecho de cualquier marca importante de confianza. Por mucho, el método más robusto para abordar esta amenaza consiste en la implementación cuidadosa de DMARC y, en particular, la herencia de DMARC.