Saltar al contenido principal

Seguridad del correo electrónico

El CEO recibe un correo electrónico de «[email protected]» pidiéndole que transfiera 50.000 € a un proveedor. El correo parece legítimo: viene de su dominio. Excepto que no es así. Un atacante suplantó su dominio porque nunca configuró la autenticación de correo electrónico. Y ahora tiene que explicarle a la junta directiva por qué alguien transfirió dinero a un estafador.

Esto les ocurre regularmente a las empresas pequeñas. La suplantación de correo electrónico no requiere ninguna habilidad técnica: las herramientas gratuitas generan correos suplantados en segundos. Sin SPF, DKIM y DMARC, cualquiera puede enviar correo electrónico que aparentemente procede de su dominio.

Este capítulo soluciona eso. Configurará la autenticación de correo electrónico para que los correos suplantados sean rechazados, y establecerá defensas básicas contra el phishing para que su equipo no caiga en los ataques que sí logran pasar.

Por qué el correo electrónico es el vector de ataque número 1

El correo electrónico es cómo empiezan la mayoría de los ataques. No porque los sistemas de correo sean inseguros, sino porque los humanos son el objetivo. Un desarrollador que nunca ejecutaría un archivo binario sospechoso hará clic felizmente en un enlace de un correo electrónico que parece provenir de GitHub.

Los ataques son simples:

Suplantación de identidad — Enviar correo electrónico que aparentemente procede de su dominio. Se usa para fraude al CEO, suplantación de proveedores y phishing de credenciales. Sin autenticación, cualquiera puede enviar como usted.

Phishing — Engañar a las personas para que hagan clic en enlaces maliciosos o introduzcan credenciales en páginas de inicio de sesión falsas. ¿El inicio de sesión de Google falso que roba su contraseña? Phishing clásico.

Business Email Compromise (BEC) — Los atacantes comprometen una cuenta de correo real (mediante phishing o credential stuffing) y la usan para solicitar transferencias bancarias, cambiar datos de pago o robar datos. Esto no es suplantación: es su propio correo electrónico siendo usado en su contra.

La autenticación de correo electrónico (SPF, DKIM, DMARC) detiene la suplantación. La formación de los empleados y los controles técnicos reducen el éxito del phishing. Ninguno es completo sin el otro.

Comprensión de SPF, DKIM y DMARC

Estos tres funcionan juntos. Cada uno resuelve un problema diferente.

SPF (Sender Policy Framework)

SPF le dice al mundo qué servidores están autorizados a enviar correo electrónico para su dominio. Es un registro TXT de DNS que lista sus remitentes autorizados.

Cuando alguien recibe un correo electrónico que dice ser de [email protected], su servidor de correo comprueba su registro SPF. Si el servidor remitente no está en la lista, el correo electrónico falla la verificación SPF.

Ejemplo de registro SPF:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Esto dice: «Solo los servidores de Google y SendGrid pueden enviar correo electrónico para nuestro dominio. Rechace todo lo demás (-all).»

El problema que SPF resuelve: Alguien que configura un servidor aleatorio y envía correo electrónico como su dominio.

Lo que SPF no resuelve: La cabecera «From» todavía puede suplantarse. SPF solo comprueba el remitente del sobre (el Return-Path), no lo que aparece en los clientes de correo.

DKIM (DomainKeys Identified Mail)

DKIM añade una firma criptográfica a sus correos electrónicos salientes. Su servidor de correo firma cada mensaje con una clave privada. Usted publica la clave pública en DNS. Los destinatarios verifican que la firma coincida.

Cómo se ve en DNS:

google._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

El problema que DKIM resuelve: Verificar que un correo electrónico no ha sido modificado en tránsito y que realmente provino de un servidor con su clave privada.

Lo que DKIM no resuelve: Por sí solo, no le dice a los destinatarios qué hacer con los correos no firmados o fallidos.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC une SPF y DKIM, y le dice a los servidores receptores qué hacer cuando falla la autenticación. También le envía informes sobre quién está enviando correo electrónico como su dominio.

Ejemplo de registro DMARC:

_dmarc.yourcompany.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Esto dice: «Si un correo electrónico falla tanto SPF como DKIM, recházalo. Envíe informes agregados a [email protected]

Los niveles de política:

  • p=none — Solo monitorización, no rechace nada (use esto primero)
  • p=quarantine — Envíe los fallos a spam
  • p=reject — Rechace los fallos directamente (el objetivo)

Lo que DMARC resuelve: Aplicar realmente la autenticación y obtener visibilidad sobre quién está suplantando su dominio.

Configuración de la autenticación de correo electrónico

Esta es la parte práctica. El orden importa.

Paso 1: audite su estado actual

Antes de cambiar nada, compruebe lo que tiene:

# Check existing SPF record
dig +short TXT yourcompany.com | grep spf

# Check DKIM (Google Workspace example)
dig +short TXT google._domainkey.yourcompany.com

# Check DMARC
dig +short TXT _dmarc.yourcompany.com

O use herramientas online:

Anote lo que encuentre. Muchas empresas tienen configuraciones parciales de hace años que nadie mantiene.

Paso 2: haga un inventario de sus remitentes de correo electrónico

Liste todos los servicios que envían correo electrónico como su dominio:

  • Correo electrónico principal (Google Workspace, Microsoft 365)
  • Correo electrónico de marketing (Mailchimp, SendGrid, HubSpot)
  • Correo electrónico transaccional (los correos de notificación de su aplicación)
  • Sistemas de soporte (Zendesk, Intercom)
  • Herramientas de RRHH/selección de personal
  • CRM que envía correo electrónico

Cada uno de estos necesita estar en su registro SPF o necesita DKIM configurado. Si olvida uno, el correo legítimo empezará a fallar.

Paso 3: configure SPF

Añada o actualice su registro SPF en DNS:

Para Google Workspace:

v=spf1 include:_spf.google.com ~all

Para Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Con servicios adicionales (ejemplo):

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all

Notas importantes:

  • Empiece con ~all (fallo suave) en lugar de -all (fallo duro). Esto pone en cuarentena los fallos en lugar de rechazarlos. Cambie a -all una vez que esté seguro de que todo está configurado correctamente.
  • SPF tiene un límite de 10 consultas DNS. Cada include: cuenta como una. Si tiene muchos remitentes, puede necesitar aplanar o consolidar.
  • Solo un registro SPF por dominio. Si tiene dos, ambos fallan.

Paso 4: configure DKIM

La configuración de DKIM varía según el proveedor. Así puede encontrar los registros que necesita:

Google Workspace:

  1. Admin Console → Apps → Google Workspace → Gmail → Authenticate Email
  2. Haga clic en «Generate New Record»
  3. Copie el valor del registro TXT y añádalo a su DNS

Microsoft 365:

  1. Microsoft 365 Defender → Email & Collaboration → Policies → DKIM
  2. Active DKIM para su dominio
  3. Añada los registros CNAME que proporcionan a su DNS

Remitentes de terceros (SendGrid, Mailchimp, etc.): Cada servicio tiene su propia configuración de DKIM. Normalmente:

  1. Vaya a la configuración de autenticación de dominio del servicio
  2. Le proporcionarán registros DNS que añadir
  3. Añádalos y luego verifique en su panel de control

Añada DKIM para cada servicio que envíe correo electrónico como su dominio. Lleva tiempo, pero es importante.

Paso 5: configure DMARC (con cuidado)

El despliegue de DMARC debe ser gradual:

Semanas 1-2: modo monitorización

v=DMARC1; p=none; rua=mailto:[email protected]

Esto no bloquea nada: solo le envía informes sobre cada correo electrónico que afirma ser de su dominio. Verá:

  • Sus remitentes legítimos
  • Cosas que había olvidado
  • Intentos reales de suplantación

Semanas 3-4: analice los informes

Los informes DMARC son archivos XML. Son ilegibles en bruto. Use una herramienta gratuita:

Busque:

  • Remitentes legítimos que fallan SPF/DKIM (corrija su configuración)
  • Remitentes desconocidos (investigue: ¿son legítimos o están suplantando?)
  • Intentos claros de suplantación (atacantes enviando como su dominio)

Semana 5 en adelante: empiece a aplicar

Una vez que esté seguro de que el correo legítimo está pasando:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Monitorice durante algunas semanas más. Si nada falla, pase al rechazo completo:

v=DMARC1; p=reject; rua=mailto:[email protected]

No se precipite. Un DMARC mal configurado con p=reject bloqueará su propio correo electrónico. El enfoque gradual lleva entre 4 y 6 semanas, pero evita interrupciones autoinfligidas.

Más allá de lo básico: MTA-STS, TLS-RPT y BIMI

Una vez que SPF, DKIM y DMARC funcionan, hay tres estándares más que vale la pena conocer.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS obliga a otros servidores de correo a usar conexiones cifradas (TLS) al enviar a su dominio. Sin él, un atacante podría degradar las conexiones a texto plano e interceptar correos electrónicos.

Configuración:

  1. Cree un archivo de política en https://mta-sts.yourcompany.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: *.mail.protection.outlook.com
max_age: 604800
  1. Añada un registro TXT de DNS:
_mta-sts.yourcompany.com TXT "v=STSv1; id=20240115"

Cambie el valor id cada vez que actualice la política.

TLS-RPT (TLS Reporting)

TLS-RPT le envía informes cuando otros servidores tienen problemas para establecer conexiones TLS con su servidor de correo. Útil para detectar problemas de certificados.

Registro DNS:

_smtp._tls.yourcompany.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"

BIMI (Brand Indicators for Message Identification)

BIMI muestra el logotipo de su empresa junto a los correos electrónicos en los clientes compatibles (Gmail, Apple Mail, Yahoo). Requiere DMARC en p=quarantine o p=reject.

Requisitos:

  1. DMARC con aplicación
  2. Su logotipo en formato SVG (requisitos específicos: use BIMI Generator)
  3. Un VMC (Verified Mark Certificate) para Gmail: cuesta ~$1.500/año de DigiCert o Entrust
  4. Registro DNS apuntando a su logotipo

Registro DNS:

default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcompany.com/logo.svg"

BIMI es opcional y tiene costes continuos. Considérelo una vez que todo lo demás esté sólido: tiene más que ver con la marca que con la seguridad, aunque ayuda a los destinatarios a confiar en que su correo electrónico es legítimo.

Solución del límite de consultas SPF

El límite de 10 consultas DNS es real y molesto. Así puede manejarlo.

Compruebe su recuento actual

Use MXToolbox SPF Record Check: muestra el total de consultas.

Cada include: genera consultas. Algunos servicios anidan múltiples includes. Google Workspace solo usa 4-5 consultas internamente.

Opción 1: elimine los remitentes que no usa

Audite qué servicios envían realmente correo electrónico. ¿Ese include de Mailchimp de 2019 cuando probó el email marketing durante un mes? Elimínelo.

Opción 2: use direcciones IP directamente

En lugar de include:sendgrid.net, puede listar los rangos de IP de SendGrid directamente:

v=spf1 ip4:167.89.0.0/16 ip4:208.117.48.0/20 include:_spf.google.com ~all

Las direcciones IP no cuentan para el límite de consultas. Pero son más difíciles de mantener: las IPs cambian.

Opción 3: aplanamiento de SPF

El aplanamiento reemplaza las declaraciones include: con las direcciones IP reales a las que se resuelven. Herramientas que automatizan esto:

La pega: los registros aplanados necesitan actualizarse cuando los proveedores cambian sus IPs. El aplanamiento manual crea carga de mantenimiento. Use un servicio si elige esta ruta.

Opción 4: divida por subdominio

Use diferentes subdominios para diferentes remitentes:

  • @suempresa.com — Solo correo electrónico principal
  • @mail.suempresa.com — Herramientas de marketing
  • @notify.suempresa.com — Notificaciones de aplicaciones

Cada subdominio tiene su propio registro SPF con su propio límite de 10 consultas.

Cómo leer las cabeceras de correo electrónico

Al investigar phishing o problemas de entrega, las cabeceras del correo electrónico cuentan la historia. Esto es lo que debe buscar.

Cómo encontrar las cabeceras

Gmail: Abra el correo → Tres puntos → «Show original» Outlook: Abra el correo → File → Properties → «Internet headers» Apple Mail: View → Message → All Headers

Cabeceras clave que comprobar

Authentication-Results — Muestra el resultado de SPF, DKIM, DMARC:

Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender);
dmarc=pass (p=REJECT sp=REJECT) header.from=company.com

Received — Cadena de servidores por los que pasó el correo. Léase de abajo a arriba (el más antiguo primero):

Received: from mail.attacker.com (suspicious-ip.com [192.168.1.1])
by your-server.com with SMTP
for <[email protected]>;
Thu, 15 Jan 2024 10:30:00 -0500

From vs Return-Path — La cabecera From: es lo que ven los usuarios. Return-Path: es lo que comprueba SPF. Si no coinciden, investigue:

Esto es suplantación clásica: el nombre para mostrar imita su dominio, pero el remitente real es diferente.

Herramientas para el análisis de cabeceras

Protección contra dominios similares

SPF/DKIM/DMARC protegen su dominio. Pero los atacantes registran dominios similares:

  • suempresa.co (TLD diferente)
  • suempresa.co (rn parece m)
  • suempresa-soporte.com (palabra añadida)
  • suemp0resa.com (sustitución de letras)

Registro defensivo

Registre variaciones obvias de su dominio, especialmente:

  • TLDs habituales (.co, .io, .net, .org)
  • Errores tipográficos de su nombre
  • Su nombre con sufijos habituales (-app, -mail, -support)

Esto cuesta dinero, pero evita la suplantación fácil.

Monitorización de dominios similares

Herramientas que escanean en busca de dominios similares recién registrados:

Gratuitas:

  • dnstwist — Código abierto, genera permutaciones y comprueba cuáles están registradas
  • URLCrazy — Similar, genera dominios de typosquatting
# Run dnstwist
dnstwist --registered yourcompany.com

Comerciales:

  • PhishLabs — Monitorización de dominios más servicios de eliminación
  • Bolster — Detección de phishing basada en IA
  • Red Points — Protección de marca incluidos dominios

Qué hacer cuando encuentra uno

  1. Compruebe si está alojando contenido (correo electrónico, sitio web)
  2. Si claramente le está suplantando, presente una queja de abuso ante el registrador
  3. Para phishing activo, informe a Google Safe Browsing y a los proveedores de navegadores
  4. Considere la eliminación legal para casos graves

Pasarelas de seguridad de correo electrónico

Para empresas que quieren más que la protección básica, las pasarelas de seguridad de correo electrónico añaden capas de filtrado, sandboxing y detección de amenazas.

Opciones basadas en la nube

Empresariales:

Mercado medio:

Para PYMES:

Cuándo necesita una pasarela

Considere una pasarela cuando:

  • Sigue recibiendo phishing significativo a pesar de DMARC
  • Necesita protección avanzada contra amenazas (sandboxing, reescritura de URLs)
  • El cumplimiento requiere archivo o cifrado de correo electrónico
  • Quiere una política centralizada para múltiples dominios

Para la mayoría de las empresas pequeñas, la seguridad nativa de Google/Microsoft más un DMARC adecuado es suficiente. Las pasarelas añaden complejidad y coste.

Protección contra BEC: procedimientos de verificación financiera

El Business Email Compromise (BEC) cuesta a las empresas más que cualquier otro tipo de ciberataque. Los controles técnicos ayudan, pero los controles de proceso son esenciales para las transacciones financieras.

La política de verificación

Ponga esto por escrito y hágalo oficial:

Para transferencias bancarias y cambios de pago:

  1. Cualquier solicitud de cambio de datos de pago debe verificarse por teléfono
  2. Use un número de teléfono conocido, no el del correo electrónico que solicita el cambio
  3. Dos personas deben aprobar las transferencias por encima de un importe determinado (establezca su umbral)
  4. Los nuevos proveedores requieren verificación antes del primer pago

Para solicitudes de datos sensibles:

  1. Las solicitudes de datos de empleados (nóminas, DNIs, etc.) deben verificarse en persona o por teléfono
  2. Nunca envíe datos sensibles por correo electrónico: use un sistema de compartición de archivos cifrado

El procedimiento de devolución de llamada

Cuando reciba una solicitud de transferencia bancaria:

  1. No responda al correo electrónico
  2. Busque el número de teléfono del remitente de forma independiente (directorio de la empresa, registros anteriores)
  3. Llámeles directamente
  4. Confirme la solicitud, el importe y los datos de la cuenta
  5. Documente la verificación

Esto lleva 5 minutos y evita pérdidas de seis cifras.

Forme específicamente al equipo de finanzas

Su equipo de finanzas es el objetivo principal del BEC. Proporcióneles formación específica:

  • Ejemplos reales de correos BEC (solicite simulaciones a KnowBe4 o similar)
  • Practique el procedimiento de verificación
  • Permiso para retrasar solicitudes sospechosas («Necesito verificar esto, lo procedo después de una llamada»)
  • Línea directa con IT/seguridad para correos sospechosos

Qué hacer si le están suplantando

Configuró los informes DMARC y descubre que alguien está suplantando activamente su dominio. ¿Ahora qué?

Acciones inmediatas

  1. Compruebe su nivel de aplicación DMARC — Si está en p=none, los correos suplantados se están entregando. Pase a p=quarantine o p=reject tan rápido como sea posible de forma segura.

  2. Alerte a sus clientes/socios — Si los atacantes le están suplantando ante sus contactos, avíseles. Un breve correo electrónico: «Hemos detectado correos electrónicos fraudulentos que afirman ser de nuestro dominio. Estamos tomando medidas. Por favor, verifique las solicitudes inesperadas a través de los canales oficiales.»

  3. Documente la suplantación — Guarde los informes DMARC, las cabeceras de correo y cualquier muestra. Puede necesitarlos para acciones legales o para las fuerzas del orden.

Rastree el origen

Los informes DMARC muestran las direcciones IP que envían correo suplantado. Puede:

  • Buscar al propietario de la IP (quién aloja el servidor del atacante)
  • Presentar quejas de abuso ante el proveedor de alojamiento
  • Informar a Spamhaus si es una fuente de spam significativa

Informe sobre las campañas de phishing

Si la suplantación forma parte de una campaña de phishing:

Soluciones a largo plazo

  1. Aplicación completa de DMARC (p=reject)
  2. Política de subdominio (sp=reject)
  3. Registro defensivo de dominios similares
  4. Monitorización continua de informes DMARC

Defensa contra el phishing: la capa humana

Los controles técnicos detienen la suplantación. Pero los atacantes todavía pueden:

  • Usar dominios similares (suempresa-soporte.com en lugar de suempresa.com)
  • Comprometer una cuenta real y enviar desde ella
  • Enviar desde su propio dominio con contenido convincente

La capa humana importa.

Formación que realmente funciona

La mayor parte de la formación en concienciación sobre seguridad es inútil. Los empleados ven diapositivas, superan un cuestionario y lo olvidan todo. Esto es lo que realmente funciona:

Muestre ejemplos reales

Recopile correos de phishing reales que se dirigieron a su empresa (o a empresas similares). Muestre al equipo:

  • Qué los hacía parecer legítimos
  • Cuáles eran las señales de alerta
  • Qué habría ocurrido si alguien hubiera hecho clic

Los ejemplos reales se recuerdan mejor que los hipotéticos.

Realice simulaciones de phishing

Envíe correos de phishing falsos a su equipo. Realice un seguimiento de quién hace clic. No se trata de castigar a las personas, sino de:

  • Medir su nivel de riesgo de base
  • Dar a las personas práctica para identificar phishing en un entorno seguro
  • Identificar quién necesita más formación

Herramientas gratuitas/baratas:

  • Gophish — Código abierto, autohospedado
  • King Phisher — Código abierto
  • Lucy — Edición comunitaria gratuita

Comerciales (más fáciles de usar):

Realice simulaciones trimestralmente. Hágalas realistas: no las haga obvias. El objetivo es la formación, no el engaño.

Enseñe el proceso de «cuando tenga dudas»

Dé a las personas una acción clara cuando no estén seguros:

  1. No haga clic en nada
  2. Reenvíe el correo a [email protected] (o a su dirección designada)
  3. Si es urgente (como una solicitud de transferencia bancaria), verifique a través de un canal separado: llame a la persona directamente usando un número conocido, no el del correo electrónico

Esto debe ser fácil. Si informar es complicado, la gente no lo hará.

Controles técnicos anti-phishing

Más allá de SPF/DKIM/DMARC:

Advertencias de correo electrónico externo

Configure su proveedor de correo para etiquetar los correos de fuera de su organización:

  • Google Workspace: Admin → Apps → Gmail → Safety → Enable external recipient warning
  • Microsoft 365: Reglas de flujo de correo → Añada el prefijo «[EXTERNAL]» al asunto

Esto recuerda a las personas que deben ser cautelosas cuando un correo dice ser de un compañero pero en realidad viene de fuera.

Análisis de enlaces y archivos adjuntos

Tanto Google Workspace como Microsoft 365 tienen análisis integrado:

  • Google: Security Sandbox, Safe Browsing
  • Microsoft: Safe Attachments, Safe Links

Actívelos. No son perfectos, pero detectan malware y dominios de phishing conocidos.

Botón de informe de phishing

Haga que informar de correos sospechosos sea con un solo clic:

  • Google Workspace: Active «Report phishing» en la configuración de Gmail
  • Microsoft 365: Active el complemento «Report Message»

Los informes deben llegar a alguien que realmente los revise.

Errores habituales que evitar

Pruebas con su propio dominio

Cuando pruebe su configuración SPF/DKIM/DMARC, no se envíe solo a usted mismo. Su servidor de correo puede tratar el correo interno de forma diferente. Envíe a un Gmail personal o use Mail Tester para obtener resultados precisos.

Olvidar los subdominios

Su política DMARC puede no aplicarse a los subdominios por defecto. Los atacantes pueden suplantar facturacion.suempresa.com aunque suempresa.com esté protegido. Añada:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

El sp=reject aplica la política a todos los subdominios.

Romper los remitentes legítimos

Pasar a p=reject demasiado rápido rompe el correo electrónico. Víctimas habituales:

  • Herramientas de marketing antiguas que nadie recuerda
  • El proveedor que usa el equipo de finanzas para enviar facturas
  • El cliente de correo personal del CEO reenviando a través de su dominio

Monitorice en modo p=none hasta que esté seguro de haberlo encontrado todo.

Límite de consultas SPF

SPF permite un máximo de 10 consultas DNS. Cada include: suele contar como una (algunos servicios anidan includes). Si supera 10, SPF falla silenciosamente.

Compruebe su recuento:

# Online tools like MXToolbox show this
# Or manually trace each include

Si supera el límite, necesita aplanar su registro SPF o eliminar los remitentes que no usa.

Protección para ejecutivos y usuarios de alto riesgo

Los ejecutivos de nivel C y los equipos de finanzas son objetivos primarios. Tienen autoridad para aprobar transacciones y acceso a información sensible. Se justifica una protección adicional.

Identifique los usuarios de alto riesgo

Cree una lista de cuentas que necesitan monitorización adicional:

  • CEO, CFO, COO y otros ejecutivos
  • Equipo de finanzas (cualquiera que pueda iniciar pagos)
  • RRHH (acceso a datos de empleados)
  • Administradores de TI (privilegios elevados)
  • Cualquiera con acceso a datos de clientes o secretos comerciales

Controles reforzados para ejecutivos

Simulaciones de phishing dedicadas

Realice simulaciones específicas para ejecutivos con ataques más sofisticados. El fraude al CEO a menudo usa urgencia y autoridad: pruebe específicamente para eso.

MFA más estricto

Exija llaves físicas (YubiKey) para los ejecutivos, no solo TOTP. Las llaves físicas son resistentes al phishing de formas en que los SMS y las aplicaciones de autenticación no lo son.

Verificación fuera de banda

Para los ejecutivos, cualquier solicitud inusual debe activar una llamada telefónica. «El CEO envió un correo pidiendo una transferencia» → Llame al número conocido del CEO antes de actuar.

Alertas de suplantación de VIPs

Algunas herramientas de seguridad de correo pueden marcar los correos que suplantan a sus ejecutivos por nombre. Google Workspace y Microsoft 365 tienen estas funciones en los niveles avanzados.

Exposición limitada del correo electrónico

Considere usar diferentes direcciones de correo electrónico:

Reduce el spear-phishing dirigido cuando los atacantes no pueden encontrar fácilmente los correos de los ejecutivos.

Compromiso de cuentas de correo electrónico: respuesta a incidentes

Cuando una cuenta de correo electrónico se compromete, la velocidad importa. Este es el manual.

Señales de compromiso

  • Contraseña cambiada inesperadamente
  • Inicio de sesión desde una ubicación/dispositivo inusual (compruebe el historial de inicios de sesión)
  • Contactos que reciben phishing de la cuenta
  • Reglas de reenvío desconocidas configuradas
  • La carpeta enviados contiene correos que el usuario no envió
  • El usuario no puede acceder a su cuenta

Respuesta inmediata (primeros 30 minutos)

  1. Restablezca la contraseña — Inmediatamente, usando la consola de administración si el usuario está bloqueado
  2. Termine todas las sesiones — Fuerce el cierre de sesión en todos los dispositivos
  3. Deshabilite temporalmente la cuenta si el compromiso es grave
  4. Compruebe y elimine las reglas de reenvío — Los atacantes las configuran para persistencia
  5. Compruebe y elimine las reglas del buzón — Busque reglas que eliminan, reenvían u ocultan correos
  6. Revise las conexiones OAuth/aplicaciones — Revoque cualquier acceso de aplicaciones de terceros sospechosas
  7. Active MFA si aún no está activado (esto debería haber prevenido el ataque en primer lugar)

Investigación (horas siguientes)

  1. Compruebe el historial de inicios de sesión — ¿Desde dónde inició sesión el atacante? ¿Cuándo empezó?
  2. Revise los correos enviados — ¿Qué envió el atacante mientras tenía el control?
  3. Compruebe si los contactos fueron atacados — ¿Usó el atacante la cuenta para atacar a otros?
  4. Identifique el punto de entrada — ¿Cómo se comprometió la contraseña? ¿Phishing? ¿Credential stuffing? ¿Malware?
  5. Compruebe el acceso a datos — ¿Qué correos/archivos vio o descargó el atacante?

Notificación (según sea necesario)

  • Interna: Alerte a los compañeros afectados si se envió phishing desde la cuenta
  • Externa: Notifique a socios/clientes si recibieron correos fraudulentos
  • Legal: Si se accedió a datos sensibles, puede tener obligaciones de notificación de brechas

Post-incidente

  1. Formación del usuario — ¿Cómo se comprometió el usuario? Aborde eso específicamente
  2. Revise la cobertura de MFA — ¿Estaba MFA activado? Si es así, ¿cómo se evitó?
  3. Documente el incidente — Para referencia futura y reconocimiento de patrones
  4. Actualice la detección — ¿Puede detectar esto más rápido la próxima vez? Añada alertas para los IOCs observados

OAuth y contraseñas de aplicaciones: acceso oculto al correo electrónico

El compromiso del correo electrónico no siempre consiste en robar contraseñas. Las concesiones de OAuth y las contraseñas de aplicaciones proporcionan acceso persistente que sobrevive a los cambios de contraseña.

La amenaza de OAuth

Cuando los usuarios hacen clic en «Iniciar sesión con Google» o «Conectar su correo electrónico», conceden tokens OAuth. Estos tokens permiten que aplicaciones de terceros lean el correo electrónico, a veces indefinidamente.

Los atacantes usan esto:

  1. Envían un correo de phishing con «Revise este documento»
  2. El usuario hace clic y llega a una pantalla de consentimiento de OAuth falsa
  3. El usuario concede acceso a la aplicación «Visor de documentos»
  4. La aplicación está controlada por el atacante y ahora tiene acceso al correo
  5. Cambiar la contraseña no revoca el token OAuth

Audite las concesiones de OAuth

Google Workspace: Admin Console → Security → API Controls → App Access Control

Revise las aplicaciones conectadas. Revoque cualquier cosa sospechosa o que no se use.

Microsoft 365: Azure AD → Enterprise Applications → User consent settings

Compruebe qué aplicaciones han recibido acceso.

Contraseñas de aplicaciones

Las contraseñas de aplicaciones son credenciales alternativas que evitan MFA. Los usuarios las crean para clientes de correo o aplicaciones que no soportan autenticación moderna.

El problema: las contraseñas de aplicaciones son tan buenas como la contraseña real, sin MFA.

Deshabilite las contraseñas de aplicaciones si sus aplicaciones soportan OAuth. La mayoría de los clientes modernos sí lo hacen. Compruebe:

  • Google Workspace: Admin → Security → Less secure apps → Disable
  • Microsoft 365: Azure AD → Authentication methods → Disable app passwords

Seguridad del correo electrónico en dispositivos móviles

Su seguridad es tan buena como el dispositivo menos seguro que accede al correo electrónico.

Controles básicos para dispositivos móviles

Requiera cifrado del dispositivo

  • iOS: Cifrado por defecto con código de acceso
  • Android: Active en Settings → Security → Encryption

Requiera bloqueo de pantalla Tanto Google Workspace como Microsoft 365 pueden aplicar una longitud mínima de PIN y biometría.

Capacidad de borrado remoto Active la capacidad de borrar datos corporativos si se pierde un dispositivo:

  • Google Workspace: Admin Console → Devices → Mobile
  • Microsoft 365: Endpoint Manager / Intune

Elección de aplicaciones móviles

Para entornos sensibles, considere:

  • Solo aplicaciones oficiales — Aplicación Gmail, aplicación Outlook (no aplicaciones de correo de terceros aleatorias)
  • Aplicaciones gestionadas — Aplicaciones que IT puede configurar y borrar por separado de los datos personales
  • Aplicaciones en contenedor — Mantenga el correo corporativo en un contenedor separado y cifrado

Consideración de MDM

La gestión de dispositivos móviles (MDM) proporciona control central pero añade complejidad. Para empresas pequeñas:

  • Google Workspace tiene MDM básico integrado (gratuito con Workspace)
  • Microsoft 365 tiene Intune (incluido en algunos planes)
  • Considere MDM si tiene requisitos de cumplimiento o datos de alto riesgo

Para la mayoría de las empresas pequeñas, requerir MFA y activar el borrado remoto es suficiente sin MDM completo.

Patrones habituales de phishing

Conocer el aspecto de los ataques ayuda a identificarlos. Estos patrones afectan regularmente a las empresas pequeñas.

La factura falsa

«Su factura está lista para pagar» con un archivo adjunto o enlace. El archivo adjunto es malware o el enlace lleva a un phishing de credenciales. Remitentes habituales: «DocuSign», «QuickBooks», «su banco».

Señales de alerta: Factura inesperada, el dominio del remitente no coincide con la empresa, urgencia.

El documento compartido

«[Nombre del compañero] ha compartido un documento con usted» de Google Drive, Dropbox o OneDrive. El enlace lleva a una página de inicio de sesión falsa.

Señales de alerta: No esperaba un documento compartido, el dominio del enlace es incorrecto (drive.google.com.malicious.com).

La suspensión de cuenta

«Su cuenta será suspendida a menos que verifique» de IT, Microsoft, Google o el banco. Crea urgencia para que haga clic sin pensar.

Señales de alerta: Saludo genérico, amenazas, urgencia, el dominio del remitente no coincide.

La solicitud del CEO

«Necesito que se encargue de algo urgentemente» aparentemente del CEO o CFO. Generalmente solicita una transferencia bancaria, tarjetas regalo o datos sensibles. A menudo afirma estar viajando o en una reunión (no se puede contactar por teléfono).

Señales de alerta: Solicitud inusual, urgencia, pide que se mantenga en confidencialidad, dirección de respuesta diferente.

La entrega del paquete

«Su paquete no pudo ser entregado» de UPS, FedEx, DHL. El enlace lleva a phishing de credenciales o malware.

Señales de alerta: Notificación de entrega inesperada, formato de seguimiento incorrecto, enlace sospechoso.

La caducidad de contraseña

«Su contraseña caducará en 24 horas» de IT. El enlace lleva a una página de inicio de sesión falsa de la empresa que roba credenciales.

Señales de alerta: IT probablemente no envíe correos sobre caducidad de contraseñas de esta manera, el enlace va a un dominio incorrecto.

Cuando el correo electrónico no es suficientemente seguro

El correo electrónico fue diseñado en una era de confianza. Para comunicaciones verdaderamente sensibles, considere alternativas.

Mensajería cifrada de extremo a extremo

Para discusiones internas sensibles:

  • Signal — El estándar de oro para la mensajería cifrada
  • Wire — Orientado a empresas, cifrado de extremo a extremo
  • Element (Matrix) — Autohospedable, código abierto

Compartición segura de archivos

No envíe documentos sensibles por correo electrónico. Use:

  • Enlace con protección por contraseña y fecha de caducidad
  • Plataformas con controles de acceso y registros de auditoría
  • Su gestor de contraseñas para compartir credenciales (Passwork, etc.)

Cuándo usar alternativas

Considere canales distintos al correo electrónico para:

  • Compartir contraseñas o claves API (use el gestor de contraseñas)
  • Discutir fusiones y adquisiciones, asuntos legales o de RRHH (mensajería cifrada)
  • Enviar contratos o documentos legales (portales seguros con registros de auditoría)
  • Comunicarse durante un incidente de seguridad (asuma que el correo está comprometido)

Herramientas y recursos

Pruebas y validación

Informes DMARC

Simulación de phishing

Gratuitas/Código abierto:

Comerciales:

Monitorización de dominios

  • dnstwist — Buscador de dominios similares de código abierto
  • PhishTank — Base de datos de phishing comunitaria
  • URLhaus — Base de datos de URLs de malware

Trucos prácticos

Algunas cosas que facilitan la seguridad del correo electrónico.

La revisión trimestral de DMARC

Configure un recordatorio en el calendario cada 3 meses para:

  1. Comprobar sus informes DMARC en busca de nuevos remitentes no autorizados
  2. Verificar que todos los remitentes legítimos siguen funcionando
  3. Buscar DKIM fallido (caducidad de certificados, cambios de servicio)
  4. Revisar su registro SPF para eliminar los servicios que ya no usa

Lleva 30 minutos. Detecta la deriva antes de que cause problemas.

Pruebe antes de cambiar el DNS

Antes de actualizar SPF/DKIM/DMARC en producción:

  1. Pruebe la sintaxis del nuevo registro con MXToolbox
  2. Establezca un TTL corto (300 segundos) antes de hacer cambios
  3. Realice el cambio
  4. Envíe correos de prueba a Mail Tester inmediatamente
  5. Si algo falla, el TTL corto significa una reversión rápida
  6. Una vez verificado, aumente el TTL a lo normal (3600+)

La colección de muestras de phishing

Cree una carpeta compartida (página de Notion, Google Doc, lo que use) donde cualquiera pueda añadir intentos de phishing que reciba. Con el tiempo construirá:

  • Una biblioteca de ejemplos reales para la formación
  • Patrones de lo que atacan a su empresa
  • Evidencia por si alguna vez la necesita para las fuerzas del orden

Haga que sea fácil añadir muestras: un formulario simple o un reenvío de correo funciona.

Reenvío vs redirección para informar

Cuando los usuarios informan de phishing, deben reenviar como archivo adjunto (no reenvío normal). El reenvío normal puede eliminar las cabeceras que necesita para el análisis.

Gmail: Seleccione el correo → Tres puntos → «Forward as attachment» Outlook: Seleccione el correo → Home → More → «Forward as Attachment»

Forme a los usuarios en esto o configure un sistema que lo gestione automáticamente.

La lista de «remitentes conocidos»

Para transacciones de alto riesgo (transferencias bancarias, datos sensibles), mantenga una lista de contactos verificados:

  • Nombre
  • Número de teléfono verificado (no del correo electrónico)
  • Dominio de correo electrónico verificado
  • Fecha de última verificación

Cuando lleguen solicitudes, compruebe con esta lista. Si el remitente no está en ella o algo parece raro, verifique antes de actuar.

Auditoría de reenvío de correo electrónico

Las reglas de reenvío de correo electrónico son un mecanismo de persistencia favorito. Los atacantes comprometen una cuenta, configuran el reenvío a su correo externo y luego reciben copias de todo incluso después de que cambie la contraseña.

Compruebe regularmente:

  • Google Workspace: Admin Console → Reports → Audit → Gmail → Filtrar por «Email forwarding enabled»
  • Microsoft 365: Security & Compliance → Threat management → Mail flow → Auto-forwarded messages

Elimine cualquier reenvío que no reconozca. También compruebe las reglas individuales del buzón (los atacantes crean reglas que reenvían correos específicos).

Lista de verificación de victorias rápidas

Cosas que puede hacer hoy:

  • Compruebe sus registros SPF, DKIM y DMARC actuales
  • Haga un inventario de todos los servicios que envían correo como su dominio
  • Active el etiquetado de correo externo en su proveedor de correo
  • Active el análisis de enlaces/archivos adjuntos
  • Configure un registro DMARC en modo p=none para empezar a recopilar datos
  • Active el botón «Informar de phishing» para los usuarios

Cosas que llevan unas semanas:

  • Configure DKIM para todos los remitentes
  • Corrija SPF para incluir todos los remitentes legítimos
  • Analice los informes DMARC y corrija los problemas
  • Pase DMARC a p=quarantine y luego a p=reject
  • Realice la primera simulación de phishing

Taller: asegure su correo electrónico

Reserve de 2 a 3 horas para la configuración inicial, con monitorización continua.

Parte 1: Auditoría y SPF (45 minutos)

  1. Compruebe los registros actuales con MXToolbox
  2. Liste todos los servicios que envían correo como su dominio
  3. Construya o actualice su registro SPF con todos los remitentes
  4. Añada/actualice el registro DNS
  5. Verifique con un correo de prueba a Mail Tester

Parte 2: Configuración de DKIM (60 minutos)

  1. Active DKIM en su proveedor de correo principal
  2. Añada los registros DNS
  3. Verifique que DKIM está firmando correos (compruebe las cabeceras de los correos enviados)
  4. Repita para cada remitente de terceros (esto lleva tiempo)

Parte 3: Despliegue de DMARC (30 minutos inicial, luego continuo)

  1. Cree el registro DMARC con p=none
  2. Configure un analizador de informes DMARC gratuito
  3. Añada el registro DNS
  4. Espere los informes (generalmente 24-48 horas)
  5. Revise semanalmente, corrija problemas, aumente gradualmente la aplicación

Parte 4: Configuración de simulación de phishing (45 minutos)

  1. Instale Gophish o regístrese en una herramienta comercial
  2. Cree una plantilla de phishing realista
  3. Importe la lista de correos de empleados
  4. Programe la simulación para dentro de unos días
  5. Revise los resultados y planifique la formación de seguimiento

Entregables:

  • SPF, DKIM y DMARC configurados
  • Monitorización de DMARC configurada
  • Primera simulación de phishing programada
  • Etiquetado de correo externo activado
  • Proceso de informes documentado

Cómo explicárselo a la dirección

Si alguien pregunta por qué invirtió tiempo en esto:

«Configuré la autenticación de correo electrónico para que la gente no pueda enviar correos falsos que parezcan venir de nuestra empresa. Antes de esto, cualquiera podía enviar correo como nuestro CEO y pedir transferencias bancarias: es un ataque habitual. Ahora esos correos quedan bloqueados. También realicé una prueba de phishing y formé al equipo en qué buscar. El phishing es como empiezan la mayoría de las brechas, y hemos reducido ese riesgo.»

Versión corta: «Hice que sea imposible suplantar nuestro correo electrónico y formé al equipo para detectar el phishing.»

Autoevaluación: ¿realmente lo hizo?

Antes de continuar, verifique que ha completado estos elementos.

Autenticación de correo electrónico

  • Registro SPF configurado con todos los remitentes legítimos
  • SPF supera la validación (sin problemas con el límite de consultas)
  • DKIM activado para el proveedor de correo principal
  • DKIM configurado para los principales remitentes de terceros
  • Registro DMARC publicado (al menos p=none)
  • Analizador de informes DMARC configurado
  • Probado enviando a Mail Tester o similar

Controles anti-phishing

  • Advertencia de correo externo activada
  • Análisis de enlaces/archivos adjuntos activado
  • Botón «Informar de phishing» disponible para los usuarios
  • Proceso para gestionar el phishing informado documentado

Formación

  • Primera simulación de phishing programada o completada
  • Proceso de «cuando tenga dudas» comunicado al equipo
  • Ejemplos reales de phishing recopilados para la formación

Si puede marcar al menos 10 de estos 14 elementos, está listo para continuar.

Qué viene después

Los controles técnicos gestionan la suplantación. Pero ningún filtro detiene un correo de phishing bien elaborado que logre pasar: eso es un problema humano.

Próximo capítulo: higiene del correo electrónico y formación en concienciación sobre phishing — el lado humano de la seguridad del correo electrónico.