10 Sep 20266 minutes read
Waseem OsmanEspecialista en DMARCAtaques RaaS: por qué su dominio de correo electrónico es el verdadero objetivo

Resumen de RaaS:
- Los afiliados de RaaS atacan los dominios de correo electrónico de forma deliberada
- Los operadores y afiliados descentralizados hacen que el modelo sea resiliente frente a las bajas
- La exposición del dominio se concentra en los márgenes: unidades de negocio adquiridas o dominios de marketing regionales
- Una política DMARC configurada en p=reject bloquea la suplantación antes y durante un incidente
Cuando los operadores de ransomware negocian con sus ejecutivos, a menudo lo hacen desde su propio dominio de correo electrónico, a menos que ya lo haya protegido.
Esto no es una hipótesis. Para los afiliados de RaaS, el compromiso del dominio no es incidental. Es el objetivo. Quien controla el dominio controla el relato: quién se entera de qué y cuándo.
Esta guía está dirigida a los responsables de riesgo, los CISO y los administradores de correo electrónico que necesitan entender por qué la autenticación de correo electrónico es una contramedida contra el RaaS, y no solo una buena práctica de higiene del correo.
Descubra la plataforma de Sendmarc y vea cómo la aplicación de DMARC bloquea el correo no autenticado antes de que llegue a las bandejas de entrada, eliminando la técnica de suplantación de la que dependen los afiliados de RaaS.
Qué es el RaaS y cómo funciona
El RaaS es un modelo de negocio del cibercrimen. Los desarrolladores crean y mantienen herramientas e infraestructura de ransomware, y luego alquilan o venden el acceso a afiliados que ejecutan los ataques. Los afiliados suelen pagar una suscripción recurrente, una tarifa única, o compartir un porcentaje de los pagos del rescate con el operador.
Esta división del trabajo es lo que distingue al RaaS de los ataques de ransomware anteriores, operados por un solo actor. Un afiliado ya no necesita escribir malware ni gestionar infraestructura de mando y control; solo necesita una vía de entrada. Ahí es donde entra la suplantación de dominio: proporciona a los afiliados el canal de entrega creíble que su arsenal técnico no ofrece por sí solo.
Por qué los afiliados de RaaS se centran específicamente en el correo electrónico
El RaaS es descentralizado por diseño: los operadores crean y mantienen la plataforma (malware, infraestructura y soporte), mientras que los afiliados independientes gestionan el compromiso inicial y la negociación por su cuenta. Esa separación es lo que le da al modelo su resiliencia; eliminar a un afiliado no afecta a la plataforma ni a los demás afiliados que la utilizan.
Como los afiliados hacen contacto por su cuenta, necesitan un mensaje que parezca fiable y un canal que siga siendo utilizable en intentos repetidos. El correo electrónico ofrece ambas cosas.
Cuando un atacante controla o puede suplantar su dominio de correo electrónico, obtiene tres ventajas en secuencia.
- Primero, pueden realizar labores de reconocimiento previas al ataque mediante mensajes de phishing que superan las comprobaciones básicas del remitente.
- Segundo, durante un incidente activo, pueden suplantar las comunicaciones internas para retrasar la detección, enviando instrucciones que parecen provenir de TI, Finanzas o el equipo directivo.
- Tercero, incluso antes de que comiencen las negociaciones, el acceso al buzón les permite leer registros financieros internos, cifras de ingresos y detalles de pólizas de seguro cibernético, y usar esa información para calibrar el monto del rescate.
El correo electrónico no es el único vector de entrada para el ransomware. Pero las empresas que blindan la autenticación del remitente eliminan una de las vías de phishing más fiables de las que disponen los afiliados de RaaS.
La debilidad de autenticación que explotan los afiliados de RaaS
DMARC, combinado con SPF y DKIM, determina si un correo que dice venir de su dominio está realmente autorizado a hacerlo. Sin la aplicación de DMARC, cualquiera puede enviar un correo que afirme provenir de su dominio. Y no necesita acceso a sus sistemas para hacerlo.
En entornos empresariales, rara vez es el dominio principal el que representa el problema. La exposición está en los márgenes: subdominios utilizados por unidades de negocio adquiridas o dominios de marketing regionales.
Los afiliados de RaaS buscan este tipo de brechas. Un subdominio con una política DMARC configurada en p=none, o un dominio cuyo SPF incluye un remitente externo que se dio de baja hace 18 meses, queda expuesto a la suplantación.
El reto en las grandes organizaciones es que ningún equipo tiene el control total del dominio. Marketing gestiona algunos registros. TI es propietario del DNS. La herramienta de Finanzas la configuró un proveedor y nunca se revisó formalmente.
Esta propiedad distribuida es exactamente lo que buscan los afiliados de RaaS durante el reconocimiento.
Dos listas de verificación: qué confirmar y qué auditar
Lista de verificación para ejecutivos
Para los CISO, la pregunta no es si existe DMARC. Es si p=reject se está aplicando realmente, quién es responsable del registro, y si puede demostrárselo a un auditor o asegurador tras un incidente.
Elementos prácticos para confirmar con su equipo:
- Qué dominios y subdominios están en p=reject hoy, y cuáles siguen en p=none o p=quarantine
- Si se están recibiendo y revisando los reportes agregados de DMARC, quién los revisa y cuál es la vía de escalamiento para remitentes desconocidos
- Si la organización puede elaborar un inventario de remitentes que enumere cada plataforma, herramienta y proveedor autorizado a enviar correo en nombre de cada dominio
Lista de verificación técnica
Los administradores de correo y los ingenieros de seguridad deben recorrer un conjunto específico de puntos de control, no como un proyecto puntual, sino como un ciclo repetible.
- Audite la cobertura de su política DMARC en todos los dominios. Esto incluye dominios aparcados, dominios heredados y cualquier subdominio utilizado por un remitente externo. Un dominio en p=none ofrece reportes, pero ninguna aplicación real. Un atacante puede enviar libremente desde ese dominio. El objetivo es p=reject en todos los dominios.
- Revise su registro SPF. Un registro SPF que incluye demasiados remitentes autorizados, o que no se ha revisado desde la última migración de plataforma, genera dos problemas: fallos de autenticación en el correo legítimo y accesos activos para servicios que ya no se usan. Revise las declaraciones include frente a su lista de proveedores actual. Elimine los remitentes que ya no estén activos.
- Confirme la firma DKIM en todos los flujos de correo saliente críticos. Los flujos críticos incluyen las comunicaciones ejecutivas, el correo de Finanzas, las notificaciones de RR. HH. y cualquier alerta generada por el sistema que pudiera ser suplantada durante un incidente.
- Revise explícitamente la política de subdominios. Una política p=reject en su dominio raíz ya cubre cada subdominio de forma predeterminada. Lo que rompe esa cobertura es un subdominio que publica su propio registro DMARC, el cual siempre tiene prioridad sobre la política raíz.
- Revise su canal de reportes agregados de DMARC. Si los reportes agregados se envían a un buzón que nadie supervisa, no aportan ningún valor operativo. Los reportes deben alimentar una plataforma que señale remitentes desconocidos o no autorizados. Durante un incidente activo de RaaS, este nivel de control del dominio marca la diferencia entre detectar un movimiento lateral a través del correo y pasarlo completamente por alto.
Durante un incidente activo: por qué el control del dominio cambia la negociación
Cuando un afiliado de RaaS ya ha desplegado el ransomware e inicia la comunicación de extorsión, las organizaciones que aplican DMARC en p=reject cuentan con una ventaja significativa de control del dominio. Los atacantes no pueden enviar correos que parezcan provenir de dominios internos.
Esto limita su capacidad de suplantar al personal en las comunicaciones internas o de generar confusión sobre qué canal de comunicación es legítimo.
Esto no es una estrategia completa de respuesta a incidentes por sí sola; es una capa más dentro de una defensa más amplia. Pero limita directamente lo que un afiliado de RaaS puede hacer con su marca mientras la extorsión sigue en curso.
Cómo ayuda Sendmarc
Sendmarc está diseñado para organizaciones que gestionan múltiples dominios, múltiples plataformas de envío y una propiedad distribuida de la infraestructura de correo electrónico: exactamente las condiciones que crean las brechas que explotan los afiliados de RaaS.
La Plataforma Sendmarc ofrece visibilidad de todos los dominios y subdominios de su cartera, señala remitentes no autorizados o no reconocidos a medida que aparecen en los datos de los reportes agregados, y hace seguimiento del estado de la política por dominio para que las áreas sin aplicación no pasen desapercibidas.
Si su organización está trabajando para alcanzar p=reject en toda su cartera de dominios, la Plataforma Sendmarc reduce la coordinación manual que normalmente frena la aplicación a gran escala.
Descubra nuestra solución de gestión de DMARC y vea cómo llevamos cada dominio a p=reject, cerrando la vía de correo no autenticado de la que dependen los afiliados de RaaS.



Leave a reply Cancelar respuesta
Your email address will not be published. Required fields are marked *