Phishing: cómo funciona un ataque y cómo identificarlo técnicamente

Respuesta rápida: qué es phishing y el modelo Confianza → Acción → Impacto #

El phishing es ingeniería social distribuida por canales digitales para inducir a una persona a revelar información, autorizar una acción, abrir contenido o iniciar un flujo que beneficia al atacante. Puede usar correo, mensajería, llamadas, QR, sitios web y servicios legítimos abusados; por tanto, phishing es el mecanismo de engaño, no el impacto final.

El ENISA Threat Landscape 2025 analizó 4.875 incidentes observados en el entorno europeo entre el 1 de julio de 2024 y el 30 de junio de 2025. Dentro de ese conjunto, ENISA situó el phishing —incluyendo vishing, malspam y malvertising— en torno al 60 % de los métodos observados de intrusión inicial. Es un dato de ese corpus y periodo, no una tasa universal aplicable a toda organización.

Para estudiar un correo sin convertir una campaña concreta en una cadena universal, esta guía usa el modelo Confianza → Acción → Impacto. Es una heurística pedagógica propia de Achirou:

1. Confianza: el mensaje intenta parecer coherente con una persona, marca, conversación o proceso real.
2. Acción: busca que la víctima haga algo: abrir un adjunto, seguir un enlace, escanear un QR, introducir credenciales, aprobar MFA o conceder permisos.
3. Impacto: el resultado puede ser robo de credenciales o tokens, fraude, acceso a información, ejecución de malware o incluso acceso inicial para un incidente posterior como ransomware.

Esta URL es el deep dive de amenaza y detección. El roadmap de Blue Team conserva la ruta de aprendizaje y habilidades de un analista SOC conserva el ownership sobre competencias del rol.

Phishing, spear phishing, whaling y Business Email Compromise (BEC) #

Estas etiquetas ayudan a describir campañas, pero no forman una taxonomía cerrada ni obligan a que cada ataque encaje en una sola categoría:

• Phishing masivo: señuelos distribuidos a muchos destinatarios con poca personalización.
• Spear phishing: mensajes dirigidos a una persona, equipo u organización concreta y adaptados a su contexto.
• Whaling: término habitual para spear phishing dirigido a perfiles de alta responsabilidad o capacidad de decisión.
• Business Email Compromise (BEC): fraude que aprovecha correo y confianza empresarial para inducir pagos, cambios de cuenta, entrega de información u otras acciones. Puede apoyarse en spoofing, dominios parecidos, cuentas comprometidas, spear phishing e incluso malware.

La guía del FBI sobre BEC describe precisamente varias vías: suplantación de cuentas o webs, spear phishing y uso de malware. Por eso no conviene definir BEC como un ataque que “no lleva enlaces ni malware”: puede no necesitarlos, pero tampoco los excluye.

Spoofing vs. Impersonation: una distinción operativa útil #

En análisis defensivo conviene separar qué identidad ve la persona de qué dominio autenticó realmente el mensaje. La terminología varía entre proveedores, por lo que esta guía usa una distinción operativa, no una clasificación normativa:

• Suplantación directa del dominio del autor: el mensaje pretende usar en From un dominio que el atacante no controla. Aquí SPF, DKIM y DMARC pueden aportar señales sobre autorización y alineación.
• Dominio lookalike o identidad visual parecida: el atacante controla un dominio diferente pero similar. Puede publicar SPF, firmar con DKIM y configurar DMARC correctamente para su propio dominio.
• Cuenta legítima comprometida: el atacante envía desde una infraestructura autorizada y una identidad real. El correo puede superar controles de autenticación y seguir siendo malicioso.

La consecuencia práctica es simple: autenticado no significa legítimo. La autenticación responde preguntas de dominio y autorización; la intención del mensaje exige contexto, contenido y telemetría.

El modelo CADENA para analizar correos sospechosos #

CADENA es un modelo pedagógico propio de Achirou; no es un framework de CISA, NIST, ENISA ni del IETF. Sirve para no reducir el triaje a “SPF/DKIM/DMARC pass o fail”.

Autenticación de correo: SPF, DKIM y DMARC en 2026 #

SPF, DKIM y DMARC son mecanismos complementarios, pero no hacen exactamente lo mismo ni se reducen todos a un registro DNS. En septiembre de 2026, las referencias técnicas relevantes son SPF RFC 7208, DKIM RFC 6376 y DMARC RFC 9989. RFC 9989 sustituyó en mayo de 2026 la especificación base de RFC 7489; los informes agregados y de fallos se separaron en RFC 9990 y RFC 9991.

Para un analista SOC, el valor está en leer qué identificador autenticó cada mecanismo y si existe alineación, no en memorizar tres luces verdes.

Por qué DMARC PASS no garantiza que un correo sea legítimo #

DMARC protege el uso autorizado del dominio del autor; no juzga el propósito del mensaje. La propia RFC 9989 explica por qué la alineación es necesaria: cualquier propietario de dominio, incluido un atacante, puede publicar SPF o firmar con DKIM para su propio dominio.

• Dominio del atacante: soporte-marca-ejemplo.net puede tener SPF, DKIM y DMARC perfectamente configurados. DMARC PASS solo indica que ese correo está autenticado y alineado con ese dominio.
• Cuenta legítima comprometida: el mensaje puede salir desde una cuenta y una infraestructura autorizadas del proveedor o empleado afectado.
• Servicio legítimo abusado: una plataforma válida puede distribuir contenido o enlaces controlados por el atacante sin que la autenticación del correo responda a la intención final.

Conclusión operativa: DMARC PASS elimina algunas hipótesis de spoofing directo, pero no cierra el caso.

Inspección de cabeceras: From, Reply-To, Return-Path y Received #

La cabecera completa de un correo aporta evidencia sobre identidad declarada, ruta y autenticación. No todos los campos tienen el mismo nivel de confianza:

• From y Display Name: muestran la identidad presentada al usuario y son especialmente útiles para detectar incoherencias o similitudes engañosas.
• Reply-To: puede ser legítimamente distinto de From, pero una discrepancia inesperada merece análisis porque cambia el destino de la respuesta.
• Return-Path: refleja la identidad de rebote establecida durante la entrega final y suele relacionarse con la identidad que SPF evalúa; no es equivalente al From visible.
• Received: cada servidor de correo añade su propio salto. Reconstruye la ruta desde la infraestructura receptora que controlas hacia atrás y establece un límite de confianza: campos Received introducidos antes de la entrada en tu infraestructura pueden haber sido manipulados por un remitente malicioso.
• Authentication-Results: prioriza los resultados añadidos por tu proveedor o gateway de confianza; un atacante puede insertar cabeceras con aspecto similar dentro del mensaje original.

Por eso “leer Received de abajo hacia arriba” no es suficiente como regla universal: primero identifica qué servidor añadió cada cabecera y cuál es el primer salto confiable.

Análisis técnico de enlaces, dominios, typosquatting y TLS #

No abras una URL sospechosa directamente desde el navegador de trabajo para “ver qué hace”. Preserva el artefacto y analiza de forma pasiva o en un entorno aislado y autorizado.

• Identifica el dominio registrable: en https://microsoft.com.portal-seguro.net/login, el host termina en portal-seguro.net; la cadena microsoft.com forma parte de un subdominio creado para inducir a error.
• Compara caracteres y contexto: sustituciones visuales, guiones, subdominios largos y dominios recién introducidos en un proceso empresarial pueden ser señales, pero ninguna es prueba aislada.
• HTTPS no equivale a legitimidad: TLS protege la conexión con el sitio al que realmente te conectas. Un atacante también puede obtener un certificado válido para un dominio que controla.
• Reconstruye redirecciones con seguridad: acortadores, enlaces de seguimiento, almacenamiento cloud y servicios legítimos pueden formar parte de una cadena. Documenta cada salto y diferencia infraestructura comprometida, abusada y controlada por el atacante.

QR phishing (quishing), PDFs y adjuntos #

El QR phishing codifica una URL u otra acción dentro de una imagen. Esto reduce las señales textuales visibles en el correo y puede desplazar la interacción a un móvil o dispositivo no gestionado. En su telemetría de correo de Q1 2026, Microsoft observó un fuerte crecimiento del QR phishing y señaló que los atacantes lo usan para intentar sortear defensas centradas en URLs de texto; esa observación describe el ecosistema Microsoft y ese periodo, no una tasa universal.

Los adjuntos también cambian con las campañas. PDF, HTML, documentos ofimáticos, archivos comprimidos u otros formatos pueden ser benignos o maliciosos según contenido y contexto. Evita convertir una lista de extensiones en una regla fija: conserva hashes, metadatos y copia original, y analiza contenido activo o comportamiento en un entorno controlado.

Navegación y telemetría: qué ocurre tras el clic (MFA, OAuth y Device Code) #

Si el usuario interactuó, el incidente deja de ser solo “un correo sospechoso”. Hay que reconstruir qué autenticación, consentimiento, sesión o ejecución se produjo:

• Credenciales y sesión: revisar inicios de sesión, IP, dispositivo, ubicación aproximada, riesgo, método de autenticación, nuevos factores registrados y actividad posterior. “IP desconocida” es una señal, no una condena automática.
• OAuth consent phishing: Microsoft documenta campañas que engañan al usuario para conceder permisos a una aplicación maliciosa. El impacto depende de los scopes concedidos, del usuario y de la política de consentimiento; no implica necesariamente robo de contraseña.
• Device Code phishing: el atacante inicia un flujo legítimo de device code y persuade a la víctima para autorizarlo. Microsoft ha documentado campañas activas en 2025–2026; el resultado puede ser la emisión de tokens a una sesión controlada por el atacante sin capturar directamente la contraseña.

En Microsoft Entra, el flujo de device code se considera de mayor riesgo y puede controlarse mediante Conditional Access. La respuesta debe basarse en la plataforma real: revisar tokens/sesiones, aplicaciones autorizadas, consentimientos y actividad de la cuenta.

Autenticación resistente al phishing: FIDO2, WebAuthn y passkeys #

NIST SP 800-63B-4 indica que los autenticadores cuyo resultado se introduce manualmente —por ejemplo, OTP— no se consideran resistentes al phishing, porque ese valor puede ser retransmitido a un verificador real. NIST cita WebAuthn como ejemplo de resistencia mediante verifier name binding.

En WebAuthn, las credenciales de clave pública están acotadas al Relying Party y el servidor debe validar el origin. Eso hace que una web impostora no pueda reutilizar una credencial para otro RP ID como lo haría con una contraseña u OTP. Las passkeys se apoyan en este modelo FIDO/WebAuthn.

La formulación correcta no es “hace imposible el phishing”: reduce una clase crítica de phishing de autenticación. Un endpoint comprometido, una sesión ya robada, ingeniería social fuera del flujo de autenticación o un consentimiento malicioso siguen exigiendo controles adicionales.

Flujo orientativo de investigación para un analista SOC #

Este flujo es una secuencia operativa orientativa, no un procedimiento universal. El orden cambia según producto, evidencia, criticidad y si hubo interacción:

1. Preservar el artefacto: obtener el mensaje original con cabeceras y, si la política lo permite, adjuntos sin ejecutarlos.
2. Validar identidad y autenticación: revisar From, Reply-To, ruta confiable, SPF, DKIM, DMARC y resultados del gateway.
3. Analizar elementos: extraer URLs, QR, dominios, hashes y metadatos. Usar sandboxes públicos solo cuando la política de privacidad y clasificación permita subir la muestra.
4. Buscar alcance: consultar correo y SIEM/SOAR por remitentes, dominios, URLs, hashes, asunto, IDs de campaña y otros indicadores. Un Message-ID o asunto por sí solos pueden ser insuficientes.
5. Reconstruir interacción: correlacionar email con identidad, proxy/DNS, endpoint y aplicaciones cloud.
6. Contener según evidencia: retirar mensajes, bloquear artefactos, resetear credenciales cuando corresponda, revocar sesiones/tokens, retirar consentimientos OAuth maliciosos y escalar al proceso de Incident Response si el alcance lo exige.
7. Documentar: separar hechos, hipótesis y acciones para que la investigación sea reproducible.

Arquitectura defensiva multicapa: reducir entrega, interacción e impacto #

• Autenticación y política de dominio: configurar SPF, DKIM y DMARC correctamente y monitorizar reporting; esto reduce abuso del dominio propio, pero no elimina lookalikes ni cuentas comprometidas.
• Seguridad de correo: filtrado de remitente/impersonation, análisis de URLs y adjuntos, detección de QR y controles de reputación/comportamiento según las capacidades del proveedor.
• Identidad: priorizar autenticación resistente al phishing donde sea viable, limitar flujos de alto riesgo y aplicar políticas de acceso condicional coherentes con el entorno.
• Aplicaciones cloud: gobernar consentimiento OAuth, revisar aplicaciones y permisos, y detectar concesiones anómalas.
• Telemetría correlacionada: conectar correo, identidad, endpoint y red para que el análisis no termine en la bandeja de entrada.
• Reporte humano sencillo: facilitar un canal claro para reportar sospechas y usar esos avisos como señal de detección, evitando convertir el entrenamiento en culpabilización del usuario.

La guía conjunta de CISA, NSA, FBI y MS-ISAC sobre phishing recomienda combinar controles técnicos y operativos para reducir tanto el robo de credenciales como la entrega de malware.

Laboratorio práctico: construir un Phishing Analysis Report #

Como propuesta pedagógica, puedes convertir el artículo en un proyecto para tu portfolio de ciberseguridad. No existe un número “correcto” de escenarios ni un requisito universal de contratación. Lo importante es demostrar un proceso reproducible.

Los escenarios pueden incluir, por ejemplo, spoofing directo, dominio lookalike autenticado, BEC, QR phishing, consentimiento OAuth o device code. Son ejercicios sugeridos, no una taxonomía obligatoria.

Conclusión y preguntas de entrevista técnica sobre phishing #

Investigar phishing exige separar lo que el mensaje afirma, lo que los protocolos autentican y lo que ocurrió después de la interacción. Un correo puede estar técnicamente autenticado y seguir siendo malicioso; también puede parecer sospechoso y resultar legítimo. El trabajo del analista es reunir evidencia y reducir incertidumbre.

Si estás preparando procesos de selección, conecta esta investigación con nuestra guía de preguntas técnicas de entrevista y practica respuestas que distingan hechos de conclusiones:

• ¿Qué identidad valida SPF y qué identidad evalúa DMARC?
• ¿Qué cambió en la especificación DMARC en mayo de 2026?
• ¿Por qué DMARC PASS no demuestra legitimidad del contenido?
• ¿Qué cabeceras consideras confiables y dónde sitúas el límite de confianza?
• ¿Qué telemetría revisarías si el usuario autorizó una aplicación OAuth o un device code?
• ¿Por qué WebAuthn puede ser resistente al phishing y un OTP manual no?

Idea final: no busques una señal mágica. Correlaciona contexto, dominio, autenticación, contenido, identidad y telemetría.