Protegerse de la suplantación de identidad (spoofing) de email

Prioridad 3: vigilar los dominios parecidos

DMARC protege el dominio exacto, pero no las variantes que puede registrar un atacante: erratas (ejemplo.es → ejempllo.es), sustituciones visuales (0/O, 1/l), o añadidos engañosos (ejemplo-seguridad.es). Estos dominios son el objetivo privilegiado del typosquatting, una técnica complementaria al spoofing puro puesto que esquiva DMARC usando un dominio realmente registrado por el atacante.

La defensa combina varios enfoques: registrar preventivamente las variantes más evidentes del propio nombre de dominio (las erratas comunes, las extensiones vecinas, las principales variaciones de TLD como .com frente a .es); vigilar los nuevos registros de dominios parecidos mediante servicios de vigilancia dedicados que alertan en cuanto una variante próxima al nombre protegido es depositada; y sensibilizar a los equipos, en particular a los que tratan transferencias y pagos, a verificar la dirección exacta en lugar de solo el nombre mostrado.

Prioridad 4: formar a los equipos expuestos a las transferencias

Incluso con DMARC en p=reject y una vigilancia sobre los dominios parecidos, el factor humano sigue siendo un punto de entrada. El fraude del CEO (BEC) explota a menudo variantes que escapan a la detección técnica: una cuenta de email legítima comprometida en otro lugar, o un dominio parecido registrado la víspera del ataque. El tema se desarrolla en el fraude del CEO (BEC): protegerse, que detalla los procedimientos organizativos que hay que poner en marcha — verificación sistemática por un segundo canal para toda transferencia inusual, en particular, así como las señales de alerta típicas que hay que enseñar a los equipos contables y financieros.

Prioridad 5: documentar y comunicar claramente

Una medida a menudo descuidada: publicar claramente, en la web y en las comunicaciones oficiales, cómo contacta realmente la organización a sus clientes o socios (qué dominios, qué prácticas). Una organización que explica públicamente «nunca pedimos una transferencia por simple email» reduce la superficie de ataque de la ingeniería social, incluso cuando el fallo técnico en sí ya está tapado por otro lado. Esta comunicación tiene también un valor defensivo directo: un cliente que recibe una petición contraria a esta política mostrada sabe inmediatamente que debe desconfiar, sin necesitar experiencia técnica para adivinarlo.

Lo que DMARC no reemplaza

Hay que ser claros sobre el reparto de papeles. DMARC es la base técnica — sin ella, todo lo demás está construido sobre arena, puesto que la usurpación directa del dominio exacto sigue siendo trivial. Pero DMARC solo no basta para una protección completa: el typosquatting, el display-name spoofing y las cuentas comprometidas exigen medidas complementarias, listadas arriba. Tratar estas cinco prioridades como un conjunto coherente, en lugar de detenerse en la primera, es lo que distingue una organización realmente protegida de una organización que cree estarlo — a menudo hasta el día en que un incidente le prueba lo contrario.

Un escenario tipo, para ver la pila de defensas en acción

Para hacer estas cinco prioridades concretas, conviene imaginar una pyme de veinte personas que acaba de descubrir que su nombre es usurpado en una campaña de phishing que apunta a sus propios clientes. Así es como cada prioridad interviene ante este escenario real.

Sin ninguna defensa en marcha, el ataque funciona a pleno rendimiento: el email dice venir de facturacion@empresa.es, llega normalmente a la bandeja de entrada (nada lo distingue técnicamente de un email real), y los clientes que hacen clic en el enlace malicioso o pagan una factura falsa no tienen ningún medio de desconfiar. La empresa, por su parte, solo descubre el incidente por las quejas de clientes que llegan a posteriori — demasiado tarde para actuar.

Con DMARC en p=reject (prioridad 1), el mismo email, usando el dominio exacto de la empresa, es rechazado antes de alcanzar el buzón del cliente. El ataque fracasa silenciosamente, sin que la empresa tenga siquiera que actuar con urgencia.

Si el atacante se repliega sobre un subdominio inexistente (facturacion.empresa.es que nunca ha sido creado), la etiqueta np (prioridad 2) bloquea igualmente ese intento — un ángulo que muchas empresas dejan abierto pensando que la protección del dominio raíz basta.

Si el atacante registra un dominio parecido (empresa-facturacion.es), DMARC no puede ya nada — es un dominio diferente, con su propia configuración. Es ahí donde la vigilancia sobre los dominios parecidos (prioridad 3) toma el relevo, detectando el registro sospechoso antes, o poco después, de su uso activo.

Si a pesar de todo un email de ese dominio parecido alcanza a un empleado con una petición de transferencia urgente, son la formación (prioridad 4) y los procedimientos de verificación por un segundo canal los que constituyen la última red.

Cada capa recupera lo que la anterior deja pasar — es exactamente por eso que las cinco prioridades funcionan juntas, y por qué detenerse en la primera (por esencial que sea) deja aún ángulos de ataque explotables.

El coste de la inacción, en perspectiva

Un último argumento para convencer a una dirección vacilante: el coste de la puesta en marcha de estas cinco prioridades es marginal comparado con el coste de un incidente exitoso. DMARC es gratis de publicar; la vigilancia sobre los dominios parecidos cuesta de unas decenas a unos cientos de euros al mes según el servicio elegido; la formación de un equipo de diez personas se cuenta en horas, no en semanas. Enfrente, un fraude del CEO exitoso se cifra comúnmente en decenas de miles de euros, sin contar el coste reputacional de una campaña de phishing llevada con éxito en nombre de la empresa, que puede mellar duraderamente la confianza de sus clientes. La asimetría entre el coste de la prevención y el coste del incidente es el argumento más convincente para priorizar este proyecto, incluso en una organización de recursos limitados.

Notemos también que las cinco prioridades no exigen el mismo esfuerzo en el mismo momento. La prioridad 1 es un proyecto con un principio y un fin — unas semanas a unos meses de inventario y alineación, luego una política endurecida que se mantiene casi sola. Las prioridades 2 y 5 son configuraciones y decisiones puntuales, resueltas en una tarde. Solo las prioridades 3 y 4 son verdaderos compromisos recurrentes: la vigilancia exige a alguien para leer las alertas, y la formación debe refrescarse al ritmo de los equipos. Vista así, la hoja de ruta es mucho menos intimidante de lo que una lista de cinco puntos deja creer — lo esencial del esfuerzo está concentrado al principio, y la carga continua sigue siendo ligera.

La prueba más rápida para situarse

Antes de priorizar los esfuerzos, una prueba simple e inmediata: ¿tiene el dominio un registro DMARC, y si es así, en qué política? Es la pregunta que determina si una organización está en la casilla de salida (suplantable directamente, prioridad absoluta) o si puede concentrarse en las prioridades siguientes (subdominios, dominios parecidos, formación) — no hay razón para construir una pila de defensas sofisticada sobre una base aún ausente.

Basta con pasar el dominio por el analizador DMARC gratuito para obtener esta respuesta en unos segundos, con el detalle de la política actual y de los subdominios. Y para situar la progresión frente al sector en el tiempo, el Observatorio DMARC da un punto de comparación útil para justificar la inversión ante una dirección que aún duda de la prioridad del tema — nada convence mejor que una cifra que muestra que competidores comparables ya están protegidos.

En resumen

Protegerse de la suplantación de dirección de email no es una acción única sino una pila de defensas complementarias: DMARC en aplicación para el dominio exacto, cobertura de los subdominios existentes e inexistentes, vigilancia sobre los dominios parecidos, formación de los equipos expuestos, y comunicación clara sobre las prácticas propias. El primer paso, el más rentable y el menos costoso, sigue siendo siempre el mismo — publicar un registro DMARC y endurecerlo metódicamente, antes de invertir en las capas siguientes.