La lección anterior recorrió los ataques técnicos y terminó con una observación: la mayoría de las cadenas de ataque no empiezan con un exploit, sino con una persona que hace algo razonable en un momento equivocado. Esta lección se ocupa de ese vector. La ingeniería social no ataca sistemas: ataca los mecanismos de decisión de las personas, y lo hace con técnicas que llevan siglos funcionando y que la tecnología solo ha abaratado. Verás por qué el factor humano es el vector dominante, qué principios de influencia explotan los atacantes, el catálogo completo de técnicas —del phishing masivo al fraude del CEO dirigido a Sara, pasando por el vishing, el quishing y el consent phishing—, cómo desmontar un correo malicioso indicador por indicador leyendo sus cabeceras, y las defensas: las técnicas del correo (SPF, DKIM y DMARC) y las de proceso, que en fraude son las que realmente detienen el dinero. Todo con un principio de fondo que conviene fijar desde ya: si tu defensa depende de que 38 personas acierten siempre, no tienes defensa.

1. Por qué el factor humano es el vector dominante
2. Los principios de influencia que explotan los atacantes
3. Catálogo de técnicas de ingeniería social
4. Anatomía de un correo de phishing dirigido a Nimbus
5. Leer las cabeceras: Received, SPF, DKIM y DMARC
6. Defensas técnicas del correo
7. Por qué Nimbus necesita DMARC también para proteger a sus clientes
8. Defensas de proceso: verificación, soporte y cultura de reporte
9. Simulacros de phishing y sus métricas

Un atacante que quiere entrar en Nimbus tiene dos caminos:

La asimetría es demoledora y explica todo lo demás:

• El atacante necesita acertar una vez; el defensor, siempre. Con 38 personas, cientos de correos al día y un ciclo de decisiones bajo presión, la probabilidad acumulada de que alguien haga clic alguna vez tiende a uno.
• No hay que vulnerar nada. Si Sara introduce su contraseña en una página falsa, no ha habido intrusión: ha habido una autenticación perfectamente válida desde el punto de vista del sistema.
• Salta por encima de casi todos los controles técnicos. El cortafuegos no ve nada anómalo, el antivirus no ve fichero, el WAF ve tráfico HTTPS normal. Es exactamente el mito 2 de 02-01.
• Escala. Enviar cien mil correos cuesta prácticamente nada; personalizar diez para objetivos concretos cuesta unas horas.

Tres precisiones importantes que cambian el enfoque:

1. La ingeniería social no explota la estupidez, explota el funcionamiento normal del cerebro humano. Cooperar con quien parece legítimo, responder rápido a lo urgente y obedecer a la autoridad son comportamientos adaptativos y necesarios para que una empresa funcione. Un equipo entrenado para desconfiar de todo no trabaja.
2. Las víctimas más frecuentes no son las menos formadas, sino las más ocupadas y las más serviciales. Rubén, que atiende decenas de tickets al día y cuya misión es ayudar, es un objetivo estructuralmente vulnerable: su trabajo consiste en hacer lo que le piden desconocidos.
3. Cualquiera pica en el día equivocado. Profesionales de seguridad experimentados caen en pruebas internas cuando el correo llega en el momento justo. Este hecho tiene una consecuencia directa sobre cómo se diseñan las defensas: no se puede construir un sistema cuyo único control sea el criterio humano.

La conclusión de diseño: las personas son una capa de detección valiosa —a menudo la primera y la única que ve un ataque nuevo—, pero nunca deben ser la única capa de prevención. La defensa contra la ingeniería social es la combinación de filtrado técnico, procesos que no dependen del criterio individual y una cultura que hace fácil reportar.

Los mensajes de ingeniería social eficaces no se improvisan: aplican de forma sistemática un puñado de resortes psicológicos bien conocidos. Reconocerlos es la mejor defensa individual, porque desplaza la pregunta de «¿parece real?» a «¿por qué siento prisa?».

Los ataques eficaces combinan principios, y la combinación clásica es autoridad + urgencia + confidencialidad:

«Soy Marta. Estamos cerrando la ronda de financiación y necesito que hagas hoy una transferencia al despacho de abogados. No lo comentes con nadie hasta que se anuncie. Te paso los datos.»

Por qué esta combinación es tan eficaz, desmontada pieza a pieza:

• La autoridad hace que cuestionar la petición se sienta como insubordinación.
• La urgencia elimina el tiempo de verificar.
• La confidencialidad —el elemento más venenoso— desactiva el único control que funcionaría: preguntar a un compañero. Nadie va a confirmar la petición con Iván si le han pedido que no lo comente.

La regla defensiva que se deriva: cuando un mensaje combina prisa con secreto, la probabilidad de fraude es altísima. Una organización sana jamás exige saltarse un procedimiento por confidencialidad. Y si de verdad lo hiciera, ese sería el problema. Esta regla, escrita y difundida, vale más que cualquier formación general.

• Al final del día o antes de vacaciones, cuando la carga cognitiva es máxima y la tolerancia a los trámites, mínima.
• Cuando la petición coincide con algo que se está esperando. Si Sara está tramitando de verdad una factura de un proveedor, un correo sobre esa factura pasa todos los filtros mentales. Por eso el OSINT y el compromiso previo de un buzón son tan rentables para el atacante.
• En una situación nueva, donde no hay procedimiento establecido: la primera vez que se contrata a un proveedor, la primera migración, el primer día de un empleado.

BEC y el fraude de cambio de cuenta bancaria. Es el que más dinero mueve y el que menos parece un ataque informático. La variante peligrosa no es la suplantación burda, sino el buzón realmente comprometido: el atacante entra en el correo de un proveedor de Nimbus, lee la conversación durante semanas, aprende el tono, los importes y el calendario, y en el momento exacto responde dentro del hilo real con una factura auténtica en la que solo ha cambiado el IBAN. No hay dominio parecido que detectar, no hay fallo de SPF: el correo viene del remitente verdadero.

Contra esto solo funciona el proceso. Ningún indicador técnico salva a Sara aquí. Lo que la salva es una regla: todo cambio de datos bancarios se verifica por teléfono, al número que ya teníamos en ficha, nunca al que aparece en el correo.

MFA fatigue. Ataca el punto débil del segundo factor por notificación push: la aprobación es un botón sin contexto. El atacante, que ya tiene la contraseña, lanza intentos repetidos hasta que la víctima acepta para que pare, o acepta medio dormida creyendo que es un fallo de sincronización. La defensa está en el propio mecanismo —number matching, límite de intentos, contexto en la notificación— y se detalla en 02-05.

Consent phishing. El más elegante y el peor entendido. El atacante no roba la contraseña: registra una aplicación con un nombre plausible y envía un enlace legítimo del proveedor de identidad. La víctima ve la pantalla real de su proveedor, con el candado correcto, y concede permisos. Consecuencias:

• El MFA no protege, porque la víctima se autentica de verdad.
• Cambiar la contraseña no revoca nada: el consentimiento sobrevive.
• El acceso es persistente mediante un token de refresco, y a menudo pasa desapercibido durante meses.

La defensa es administrativa: desactivar el consentimiento libre de usuario, exigir aprobación del administrador para aplicaciones nuevas y revisar periódicamente las aplicaciones autorizadas en el tenant de correo de Nimbus.

Este es el correo que recibe Sara un jueves a las 17:40. Está construido con todo lo del apartado 2. Analízalo antes de leer el desmontaje.

Es la habilidad práctica más rentable de toda la lección, y casi nadie la enseña bien.

La regla: el dominio real son las dos últimas etiquetas antes de la primera barra. Todo lo que va delante son subdominios que controla quien posee el dominio real. Cualquiera puede crear banco.tuempresa.example.midominio.example.

Compara:

Consejo operativo: en un correo dudoso no se hace clic para comprobar. Se pasa el ratón por encima y se lee la barra de estado, o mejor: se escribe la dirección conocida en el navegador. Si el mensaje era legítimo, el aviso estará también dentro de la aplicación.

Las cabeceras son la parte del correo que el atacante controla peor. Saber leerlas convierte una sospecha en un diagnóstico.

Cada servidor por el que pasa un correo añade una cabecera Received al principio. Por tanto se leen de abajo hacia arriba para seguir el recorrido cronológico.

Qué se saca de aquí:

• El correo nació en 203.0.113.99 (línea inferior), no en la infraestructura de Nimbus.
• ESMTPA en el primer salto indica que el emisor se autenticó en ese servidor de salida: alguien tiene una cuenta en ese proveedor, dato útil para una denuncia.
• unknown significa que la resolución inversa de la IP no coincide con el nombre declarado: señal de baja reputación.
• Solo son fiables las cabeceras añadidas por servidores que tú controlas (las de arriba). Las inferiores las puede falsificar el atacante, así que se usan como indicio, no como prueba.

El punto clave que casi todo el mundo pasa por alto: SPF y DKIM, por separado, no protegen contra la suplantación del From visible. Un atacante puede publicar SPF y DKIM válidos para su propio dominio y aun así poner From: Marta <[email protected]>. Lo que ata las tres piezas es DMARC, mediante el requisito de alineación: el dominio del From debe coincidir con el del SPF o el del DKIM.

Traducción línea a línea:

• spf=fail: la IP 198.51.100.203 no está entre las autorizadas por el dominio del sobre.
• dkim=none: no hay ninguna firma. No es que sea inválida: no existe.
• dmarc=none (p=NONE ... dis=NONE): el dominio del atacante o no publica DMARC o lo publica en modo pasivo; dis=NONE indica que no se ha aplicado ninguna disposición, es decir, el correo se ha entregado.

Y aquí está la lección incómoda: el correo llegó igualmente a la bandeja de entrada de Sara pese a fallar SPF y no tener DKIM. Por dos motivos: el dominio del atacante es suyo y puede configurarlo como quiera, y el filtro de Nimbus no estaba configurado para actuar sobre estos fallos. Un compromiso razonable —enviar a cuarentena lo que falla SPF y añadir un aviso visible— habría cambiado el desenlace.

Compáralo con un correo legítimo:

spf=pass, dkim=pass con el selector sel2026, y dmarc=pass con política p=REJECT: el dominio del From está alineado y, si no lo estuviera, el destinatario habría rechazado el mensaje.

Anatomía del registro, campo a campo:

El error más común: terminar en ~all (softfail) «por si acaso» y dejarlo así para siempre. ~all dice al destinatario «esto es sospechoso, pero acéptalo». La mayoría de los buzones lo entregan igualmente. Se empieza con ~all durante la puesta en marcha y se termina en -all; si no, SPF es decorativo.

Dos limitaciones que hay que conocer:

1. SPF se rompe con el reenvío. Si un cliente reenvía un correo de Nimbus, la IP emisora pasa a ser la de su servidor y SPF falla. Por eso DKIM es imprescindible: sobrevive al reenvío.
2. Límite de 10 consultas DNS. Encadenar muchos include: supera el límite y el resultado pasa a ser permerror, que equivale a no tener SPF. Hay que revisarlo cada vez que se añade un proveedor.

Nimbus firma cada correo saliente con una clave privada; el destinatario recupera la clave pública del DNS y verifica.

Qué aporta DKIM que SPF no puede: garantiza la integridad (el cuerpo y las cabeceras firmadas no se han alterado) y sobrevive al reenvío, porque no depende de la IP. La firma se ve en la cabecera DKIM-Signature del mensaje. El detalle de cómo funciona una firma digital se estudia en 03-03 y 03-04; aquí basta con saber leer el resultado.

El despliegue correcto, por fases, que es donde fracasan la mayoría de las implantaciones:

Por qué no se puede saltar la fase 1. Nimbus envía correo desde al menos cinco sitios: el servidor propio, el proveedor de email transaccional (recordatorios de cita), la herramienta de facturación, la plataforma de marketing y quizá el CRM. Pasar directamente a p=reject bloquea los recordatorios de cita de los pacientes, lo que sería un incidente de disponibilidad autoinfligido. Los informes rua de la fase 1 revelan exactamente qué emisores existen —incluidos los que nadie recordaba— antes de endurecer nada.

Hasta aquí, DMARC parecía una defensa para Nimbus. Es la mitad de la historia y la menos importante.

Nimbus envía a diario recordatorios de cita a pacientes de clínicas. Esos pacientes están acostumbrados a recibir correos de nimbusreservas.example. Si Nimbus no publica DMARC con política de rechazo, cualquiera puede enviar correos que se muestren como procedentes de Nimbus, y llegarán a la bandeja de entrada de esos pacientes.

El escenario concreto:

1. Un atacante envía a diez mil direcciones un correo con From: [email protected].
2. El mensaje dice: «Su clínica ha actualizado la política de pagos. Confirme sus datos bancarios para mantener su cita.»
3. Como Nimbus no publica DMARC, el correo se entrega sin ningún aviso.
4. Los pacientes que caen, caen en nombre de Nimbus.

Las consecuencias, ordenadas por gravedad:

• Daño reputacional directo al activo A-20: las clínicas culparán a Nimbus, con razón.
• Deterioro de la entregabilidad: cuando un dominio se usa masivamente para fraude, su reputación cae y los recordatorios legítimos empiezan a ir a spam. Nimbus perdería su canal operativo principal.
• Exposición contractual y regulatoria: los clientes preguntarán qué medidas había, y «ninguna» es una respuesta difícil de sostener cuando la medida cuesta un registro DNS.

La formulación que conviene recordar: SPF, DKIM y DMARC no protegen tu buzón de entrada; protegen tu dominio de ser usado contra otros. Son medidas de higiene hacia fuera, no de defensa hacia dentro. Y por eso son especialmente importantes para un SaaS que envía correo en nombre de sus clientes.

Nota adicional para el caso de Nimbus: si en el futuro los clientes quieren que los recordatorios salgan desde su dominio ([email protected]), habrá que documentar cómo delegan el envío —normalmente con un subdominio delegado y su propio DKIM— sin romper su DMARC. Es una conversación técnica que conviene tener antes de vender la funcionalidad.

Nota sobre implicaciones legales: un correo fraudulento enviado en nombre de Nimbus a pacientes de sus clientes puede tener implicaciones en materia de protección de datos y de relación contractual con el cliente. Ante un caso real, valóralo con el responsable de cumplimiento y con asesoría jurídica; el tratamiento se aborda en 06-03.

Las defensas técnicas paran volumen. Lo que para el fraude dirigido es el proceso, porque un proceso no se cansa, no tiene prisa y no se deja impresionar por la autoridad.

La regla de oro, redactada para colgarla en la pared:

Toda petición de pago, de cambio de datos bancarios o de credenciales que llegue por escrito se verifica por un canal distinto, usando un contacto que ya teníamos, antes de ejecutarla. Sin excepciones por urgencia y sin excepciones por jerarquía.

Las cuatro palabras que hacen que funcione:

• Canal distinto: si llegó por correo, se verifica por teléfono o en persona. Responder al correo no vale: puede estar controlado.
• Contacto que ya teníamos: el número de la ficha del proveedor o del directorio interno, nunca el que aparece en el mensaje.
• Antes de ejecutarla: verificar después de transferir es una autopsia.
• Sin excepciones: una regla con excepciones por urgencia se convierte en una regla que solo se aplica cuando no hace falta. Y la urgencia es justamente el resorte del ataque.

Procedimiento concreto para Nimbus (dueña del proceso: Sara):

Un detalle que evita el fallo más habitual: hay que dar permiso explícito y por escrito para decir que no a la dirección. Si Sara sabe que Marta la respaldará por retrasar un pago para verificarlo, verificará. Si teme la reprimenda, no lo hará. La regla no la protege si la cultura la contradice.

Rubén es el objetivo estructural: recibe peticiones de desconocidos y su función es ayudar. Necesita un procedimiento que le permita ayudar sin decidir bajo presión.

Escenario típico de vishing: llamada al soporte de Nimbus. «Hola, soy Carlos, el nuevo administrador de Clínica Turia. Estoy en consulta con pacientes esperando y no puedo entrar al panel. ¿Me puedes resetear la contraseña o darme acceso temporal? Es urgente, tengo la sala llena.»

Ahí están autoridad (administrador del centro), urgencia (pacientes esperando) y simpatía. Y una petición que suena perfectamente razonable.

Procedimiento de verificación en tres niveles:

Las tres reglas que sostienen el procedimiento:

1. La llamada de vuelta al número de ficha lo resuelve casi todo. Rompe el ataque sin necesidad de que Rubén juzgue si la historia es creíble.
2. Nunca se pide ni se acepta un código de verificación. Ningún soporte legítimo —ni el de Nimbus, ni el del banco, ni el del proveedor cloud— pide el código que acaba de recibir el usuario. Si alguien lo pide, es un ataque, sin más análisis.
3. La presión es un indicador, no una razón. Cuanta más prisa mete el interlocutor, más despacio hay que ir. Conviene entrenar una frase concreta: «Claro, te llamo yo ahora mismo al número que tenemos en ficha y lo resolvemos.»

Este apartado es el que más incidentes evita, porque el tiempo entre el clic y el aviso determina el desenlace.

Instrucciones para cualquier empleado de Nimbus, en orden:

1. Avisa inmediatamente. Canal único y conocido: [email protected] o mensaje directo a Lucía. Antes de intentar arreglarlo por tu cuenta.
2. Si introdujiste una contraseña, cámbiala en el sitio real —escribiendo la dirección a mano— y avisa igualmente. Si la reutilizabas en otro sitio, cámbiala también allí.
3. Si aprobaste una notificación MFA que no habías pedido, avísalo: significa que alguien tiene tu contraseña.
4. Si abriste un adjunto, desconecta el equipo de la red (wifi y cable) y no lo apagues: apagarlo destruye evidencia útil. Espera instrucciones.
5. Si hiciste una transferencia, llama al banco de inmediato: existe una ventana de horas para intentar la retrocesión.
6. No borres el correo. Es la evidencia que permite buscar a quién más le llegó.

Y la regla cultural, que es la más importante de toda la lección:

A quien reporta no se le culpa. Nunca. Bajo ninguna circunstancia.

El razonamiento, que conviene poder explicar a la dirección: si castigas al que informa, el siguiente no informará. Un clic reportado en 5 minutos es un incidente contenido; el mismo clic reportado a las tres semanas —o no reportado— es una brecha. El comportamiento que quieres reforzar no es «no picar» (imposible de garantizar) sino «avisar rápido» (perfectamente alcanzable). Una organización que celebra los reportes obtiene más reportes, y con ellos detección temprana gratis.

Corolario práctico: los resultados individuales de los simulacros no se publican, no se comparan y no entran en la evaluación del desempeño. Se usan de forma agregada para medir el programa, no a las personas.

Un simulacro es un envío controlado de correos de phishing benignos al propio equipo, para medir y entrenar. Bien hechos son la herramienta de concienciación más eficaz; mal hechos generan resentimiento y destruyen la confianza. El programa formativo completo se desarrolla en 06-05; aquí solo lo necesario para entenderlos como defensa.

Por qué la tasa de reporte importa más que la de clic. La tasa de clic mide algo que nunca llegará a cero: siempre habrá alguien ocupado en el momento equivocado. La tasa de reporte mide algo que sí puedes llevar muy arriba y que aporta un valor operativo directo: cada reporte es una alerta temprana. Un equipo con 12 % de clic y 55 % de reporte está mucho mejor defendido que uno con 6 % de clic y 3 % de reporte, porque en el segundo nadie se entera de nada.

El tiempo hasta el primer reporte es igualmente crítico: si el primer aviso llega a los 6 minutos, Lucía puede buscar el mensaje en todos los buzones, eliminarlo y bloquear el dominio antes de que la mayoría lo abra. Un solo empleado atento protege a los otros 37.

Buenas prácticas:

• Anunciar el programa, no los envíos. Todo el mundo debe saber que habrá simulacros periódicos; nadie debe saber cuándo.
• Dificultad progresiva. Empezar con señuelos genéricos y subir gradualmente hacia el escenario dirigido, para que la mejora sea medible.
• Formación inmediata en el momento del clic, breve (dos minutos) y sin tono acusador: qué indicadores tenía este correo concreto.
• Medir siempre la tasa de reporte, no solo la de clic. Si tu plataforma no la mide, cambia de plataforma.
• Resultados agregados, jamás individuales ni ligados al desempeño.
• Cerrar el ciclo: compartir con todo el equipo los indicadores del correo usado. Lo que enseña no es el envío, es la explicación posterior.

Prácticas que hacen daño y hay que evitar:

• Usar señuelos crueles: falsas primas, falsos despidos, falsas noticias médicas. Consiguen tasas de clic altísimas y destruyen la confianza en el programa y en RRHH durante años.
• Publicar quién picó. Convierte el simulacro en un castigo público y garantiza que nadie vuelva a reportar nada.
• Medir solo el clic y presentarlo a dirección como si fuera el nivel de seguridad de la empresa.
• Hacer un simulacro al año. Es una foto, no un programa. Trimestral es un ritmo sostenible para Nimbus.
• Suplantar a personas reales del equipo sin acuerdo previo. Usar el nombre de Marta en un señuelo puede dañar la relación de confianza interna; se puede hacer, pero debe estar acordado y explicado después.

Errores comunes:

• Creer que la formación resuelve el problema. Reduce la tasa de clic, no la lleva a cero. La formación es una capa; el proceso y el filtrado son las otras dos.
• Confiar en «reconocer las faltas de ortografía». Los correos dirigidos actuales están bien escritos, en español correcto y con contexto real de la empresa. Ese consejo está obsoleto y da falsa confianza.
• Culpar al que reporta. El error más caro de todos: destruye la única fuente de detección temprana que tiene una PYME.
• Publicar DMARC en p=none y darlo por hecho. Sin política de rechazo, DMARC solo informa. Miles de dominios llevan años en p=none.
• Verificar respondiendo al mismo correo. Si el buzón está comprometido, responde el atacante. El canal alternativo es lo que define la verificación.
• Pedir el código de verificación a un usuario en soporte. Legitima el ataque de vishing más común. Nunca, en ningún caso.
• Pensar que el consent phishing lo para el MFA. No lo para: la víctima se autentica de verdad y concede permisos voluntariamente.
• Bloquear el QR como problema menor. El quishing traslada el ataque al móvil personal, fuera del alcance de todos los controles corporativos.
• Diseñar el procedimiento de pagos sin la persona que paga. Un procedimiento que Sara no puede cumplir en su día a día no se cumple.

Consejos:

• Enseña una sola habilidad técnica a todo el equipo: leer un dominio de derecha a izquierda. Es la que más ataques detiene por minuto de formación.
• Instala el banner de correo externo esta semana. Coste cero, eficacia alta contra el fraude del CEO.
• Escribe la regla de verificación de pagos en una página, con umbrales concretos, y haz que Sara y Marta la firmen. Un procedimiento sin dueño ni umbrales no se aplica.
• Da al equipo una frase de escape entrenada para el teléfono: «Te llamo yo al número que tenemos en ficha». Tener la frase preparada evita el bloqueo ante la presión.
• Revisa hoy las aplicaciones OAuth autorizadas en el correo corporativo de Nimbus y desactiva el consentimiento libre de usuario.
• Comprueba tus tres registros con dig ahora mismo: SPF (-all), DKIM (selector activo) y DMARC (p= y rua=). Es un diagnóstico de tres minutos.
• Mide la tasa de reporte desde el primer simulacro y preséntala a dirección como métrica principal, por delante de la tasa de clic.

Iván recibe este mensaje un martes por la mañana:

Se pide: (a) enumera todos los indicadores de fraude que encuentres; (b) explica el detalle más peligroso de este correo en concreto, que lo hace más difícil de detectar que el de Sara; (c) indica qué debe hacer Iván, paso a paso; (d) di qué defensa técnica de las del apartado 6 lo habría marcado y cuál no.

Nimbus ha estado a punto de perder 14.200 € en un fraude de cambio de IBAN. Marta te pide un procedimiento de una página que Sara pueda aplicar de verdad.

Se pide:

1. Redacta la regla general en una sola frase.
2. Define una tabla de umbrales y verificaciones para: proveedor nuevo, cambio de IBAN de proveedor existente, pago superior a 3.000 €, cambio de cuenta de nómina y devolución a un cliente.
3. Especifica qué se registra de cada verificación y dónde.
4. Indica tres formas concretas en que el procedimiento podría fallar en la práctica y cómo prevenirlas.
5. Explica qué debe hacer Sara si Marta en persona le pide saltarse el procedimiento.

Nimbus realiza su primer simulacro trimestral. Se envía a los 38 empleados un correo que suplanta al proveedor de email transaccional pidiendo revalidar credenciales.

Se pide: (a) calcula e interpreta las métricas del apartado 9.1; (b) di cuál es el dato más preocupante del cuadro y por qué; (c) propón cinco acciones concretas para el trimestre siguiente, ordenadas por impacto esperado; (d) explica qué no debe hacerse con estos resultados, en particular con el dato de Soporte.

Solución 1

(a) Indicadores presentes:

1. Dominio parecido en el remitente: github-security-alerts.example no es el dominio real del proveedor. Es un dominio propio del atacante, con aspecto corporativo.
2. Enlace enmascarado: https://github.com.security-alerts.example/.... Leído de derecha a izquierda, el dominio real es security-alerts.example; github.com es solo un subdominio. Es el mismo truco del correo de Sara, aquí más eficaz porque incorpora un .com que induce a leer mal.
3. Urgencia con amenaza: «suspensión automática en 24 horas» — miedo + urgencia.
4. Pretexto técnicamente creíble y personalizado: menciona el repositorio real, un commit y un fichero con número de línea. Casi con seguridad obtenido por OSINT si el repositorio fue público alguna vez, o simplemente inventado con nombres plausibles.
5. Petición de iniciar sesión desde el enlace: los avisos legítimos piden ir al sitio, no ofrecen la puerta.
6. Saludo en minúscula y sin apellido (Hola ivan): sugiere plantilla generada a partir de la parte local del correo.
7. Emisor incoherente: smtp7.envio-masivo.example no es infraestructura del proveedor suplantado.

(b) El detalle más peligroso: SPF, DKIM y DMARC pasan todos. Y eso es correcto, porque el atacante ha configurado bien su propio dominio. Aquí está la lección esencial:

La autenticación de correo verifica que el mensaje viene realmente del dominio que dice el From. No verifica que ese dominio sea de fiar. Un dmarc=pass de un dominio registrado ayer por un estafador es un pass perfectamente válido.

Muchos usuarios y no pocos técnicos interpretan «autenticación superada» como «correo legítimo». Es un error de categoría, y este correo lo explota. El correo de Sara fallaba SPF y era fácil; este pasa todo y es difícil.

(c) Qué debe hacer Iván:

1. No pulsar el enlace.
2. Abrir el navegador y escribir a mano la dirección del proveedor real. Si hubiera una alerta de secreto expuesto, estaría allí.
3. Reportar el correo al canal oficial sin borrarlo, para que Lucía pueda buscarlo en el resto de buzones y bloquear el dominio.
4. Independientemente de que el correo sea falso, comprobar si de verdad hay un secreto en config/settings.py. El pretexto puede ser inventado, pero el problema podría existir; y si existe, hay que rotar la credencial, no solo borrarla del código (sigue en el historial de Git).
5. Si por cualquier motivo llegó a introducir credenciales: cambiar la contraseña en el sitio real, revocar sesiones y tokens activos, y avisar de inmediato.

(d) Defensas técnicas:

• Lo habrían marcado: el aviso de dominio parecido al de un proveedor habitual; la reescritura y comprobación de enlaces en el clic (el destino es un dominio recién registrado y de baja reputación); la reputación del dominio, por edad de registro; y el banner de correo externo, que al menos recuerda que no es interno.
• No lo habría marcado: SPF, DKIM ni DMARC, porque el atacante los cumple para su propio dominio. Tampoco el filtro de adjuntos: no hay adjunto. Y un antivirus no ve nada, porque no hay fichero.

Solución 2

1. Regla general:

«Ninguna orden de pago, cambio de datos bancarios o alta de beneficiario se ejecuta solo con una petición escrita. Se verifica siempre por un canal distinto, con un contacto que ya estaba en nuestra ficha, y se deja constancia de quién verificó, cuándo y con quién habló. La urgencia no exime; la jerarquía tampoco.»

2. Tabla de umbrales:

3. Registro. En el sistema de gestión, junto al asiento: fecha y hora de la verificación, nombre de quien verificó, nombre y teléfono del interlocutor, canal usado, y resultado. Sin registro, la verificación no ha ocurrido a efectos de auditoría (06-04).

4. Tres formas de fallar y su prevención:

5. Si Marta en persona pide saltarse el procedimiento. Sara debe aplicarlo igualmente, y esa es precisamente la razón de existir de la regla: el procedimiento protege también a Marta, porque impide que alguien que la suplante consiga un pago. La formulación práctica: «Claro, lo tramito ahora mismo; solo necesito la confirmación de la segunda firma, como en todos los pagos.» Para que esto sea posible, Marta debe haber declarado por escrito y ante todo el equipo que nadie será reprendido por aplicar el procedimiento a la dirección. Sin ese respaldo explícito, ningún procedimiento antifraude sobrevive al primer contacto con la jerarquía.

Solución 3

(a) Métricas:

(b) El dato más preocupante. No es el 29 % de clic: es la combinación de tasa de reporte del 11 % y 47 minutos hasta el primer aviso. Razonamiento: el clic siempre existirá, pero en un ataque real esos 47 minutos son la diferencia entre borrar el correo de 38 buzones antes de que la mayoría lo abra y descubrir el incidente semanas después por sus consecuencias. Además, seis personas entregaron credenciales y solo una de las que interactuaron avisó: significa que las otras cinco sabían o sospechaban que algo iba mal y no lo dijeron. Eso apunta a un problema de cultura, no de conocimiento, y la cultura es lo que hay que arreglar primero.

(c) Cinco acciones, por impacto esperado:

1. Comunicar y hacer visible el canal de reporte, con un botón de «Reportar phishing» en el cliente de correo y un mensaje explícito de la dirección: reportar siempre se agradece, picar nunca se sanciona. Ataca directamente la métrica peor.
2. Sesión de 30 minutos con el análisis del correo real usado, indicador por indicador, incluida la lectura del dominio de derecha a izquierda. Cerrar el ciclo es lo que convierte el simulacro en formación.
3. MFA resistente al phishing en todas las cuentas, priorizando las administrativas. Con MFA adecuado, esas seis credenciales entregadas no habrían bastado para entrar. Es la medida que más reduce el impacto con independencia de la tasa de clic (02-05).
4. Activar el banner de correo externo y el aviso de dominio parecido, si no lo están. Coste casi nulo, efecto inmediato sobre el reconocimiento.
5. Sesión específica y de apoyo con el equipo de soporte, no por su tasa de clic sino porque su exposición es estructuralmente mayor: junto con la sesión, dotarles del procedimiento de verificación de identidad del apartado 8.2, que les quita la carga de decidir.

(d) Qué NO hacer:

• No publicar ni comunicar quién picó, ni en agregado por persona ni en una lista.
• No señalar a Soporte como «el departamento problemático». Sus tres clics de cuatro personas reflejan que su trabajo consiste en abrir mensajes de desconocidos y ayudarles: es un dato sobre el diseño del puesto, no sobre las personas. Tratarlo como falta personal garantiza que soporte no vuelva a reportar nada, justo el equipo que más ataques ve.
• No vincular los resultados a la evaluación del desempeño ni a incentivos.
• No presentar a dirección solo la tasa de clic. El indicador principal debe ser la tasa de reporte y el tiempo hasta el primer aviso, que son las que miden la capacidad real de reaccionar.
• No dar el problema por resuelto con un correo informativo. Sin cambios en MFA, en filtrado y en el procedimiento, el próximo simulacro dará resultados casi idénticos.

Has estudiado el vector que encabeza casi todas las estadísticas de incidentes. Sabes por qué el factor humano es dominante: la asimetría es aplastante —el atacante necesita acertar una vez, el defensor siempre— y el ataque no vulnera nada, sino que consigue que alguien haga voluntariamente lo que se le pide. Has visto que la ingeniería social no explota la ignorancia sino el funcionamiento normal del criterio humano, y que los objetivos más frecuentes son los más ocupados y los más serviciales, como Rubén, cuyo trabajo consiste literalmente en ayudar a desconocidos. De ahí la conclusión de diseño que estructura toda la lección: las personas son una excelente capa de detección y una pésima única capa de prevención.

Has aprendido los principios de influencia —autoridad, urgencia, escasez, reciprocidad, prueba social, simpatía, miedo y coherencia— y la combinación más peligrosa, autoridad más urgencia más confidencialidad, cuyo tercer ingrediente existe para desactivar el único control que funcionaría: preguntar a un compañero. Has recorrido el catálogo de técnicas, del phishing masivo al BEC desde un buzón realmente comprometido, el fraude de cambio de IBAN dirigido a Sara, el smishing, el vishing, el quishing, el baiting, el tailgating, el MFA fatigue y el consent phishing que ni el MFA ni el cambio de contraseña detienen. Has desmontado un correo completo con sus doce indicadores y has aprendido la habilidad más rentable de todas: leer un dominio de derecha a izquierda. Y has aprendido a leer cabeceras: la cadena Received de abajo arriba, y el significado exacto de spf=fail, dkim=none y dmarc=none, junto con la lección que da el ejercicio de Iván —que un dmarc=pass acredita el dominio, no la honradez de quien lo registró.

En defensas técnicas has visto SPF con su -all decisivo, DKIM con su selector y su capacidad de sobrevivir al reenvío, y DMARC como la pieza que ata las anteriores mediante la alineación, con un despliegue por fases que no se puede saltar sin dejar sin recordatorios a los pacientes de las clínicas. Y has entendido lo que casi nadie explica: que estos tres registros no protegen tu buzón, protegen tu dominio de ser usado contra otros, lo que en el caso de Nimbus significa proteger a los pacientes de sus clientes. En defensas de proceso te llevas la regla de verificación por canal alternativo con contacto de ficha, el procedimiento de tres niveles para el soporte de Rubén, el qué hacer si has picado, y la regla cultural que sostiene todo lo demás: a quien reporta no se le culpa nunca, porque el comportamiento que se puede garantizar no es «no picar», sino «avisar rápido». Los simulacros te han dado las métricas correctas, con la tasa de reporte y el tiempo hasta el primer aviso por delante de la tasa de clic.

Conocido el catálogo completo de ataques —técnicos en 02-02 y humanos aquí— toca ordenar la respuesta. En la siguiente lección, Medidas de Protección en Ciberseguridad (02-04), recorreremos el catálogo de defensas organizado por las capas de la defensa en profundidad: perímetro y red, endpoint, dato, aplicación y ciclo de desarrollo, y registro y observabilidad; con un ejemplo de flujo de CI que analiza dependencias y secretos, y con lo más útil para una PYME: una tabla de las doce medidas de mayor retorno para Nimbus y un plan por fases de 30, 90 y 180 días.