Qué hacer si un empleado cae en un phishing: guía de respuesta paso a paso
Por Kike Gandia · Co-Fundador y CEO, OSCP
Si un empleado ha caído en un phishing, lo primero es que lo cuente ya, sin miedo a represalias, y lo segundo es contener: cambiar su contraseña, revocar las sesiones abiertas y, si ejecutó algún archivo, desconectar el equipo de la red sin apagarlo. Si además hizo una transferencia, la llamada al banco va antes que todo lo demás. El resto de la respuesta depende de qué hizo exactamente, porque no es lo mismo abrir un correo que escribir la contraseña en una web falsa o aprobar un aviso de MFA. Esta guía ordena los pasos por urgencia, desde el primer minuto hasta las notificaciones obligatorias y las lecciones aprendidas.
Paso 1: que el empleado avise ya y sin miedo a represalias
Lo que más cambia el desenlace de un phishing no es el error en sí, sino el tiempo que pasa hasta que alguien lo sabe. Con unas credenciales robadas, un atacante puede entrar en el buzón, crear reglas para ocultar su actividad y empezar a escribir a clientes y proveedores en muy poco tiempo. Si el empleado tarda un día en contarlo por vergüenza, la contención llega tarde.
Por eso el mensaje a la plantilla, y el que conviene repetir en cada formación, es sencillo: si crees que has caído, avisa ya, aunque no estés seguro. Quien avisa rápido ha hecho lo correcto. Si la respuesta de la empresa es buscar un culpable, la próxima vez nadie avisará, y ese silencio sale mucho más caro que cualquier clic.
Cuando llegue el aviso, recoge de inmediato:
- Qué hizo exactamente: abrir el correo, hacer clic, escribir la contraseña, aprobar un aviso de MFA, descargar o ejecutar un archivo, transferir dinero o dar acceso a su equipo.
- Cuándo: la hora aproximada acota qué registros hay que revisar.
- Desde qué dispositivo: portátil corporativo, móvil personal o equipo de casa.
- El correo original: que no lo borre. Hará falta para buscarlo en otros buzones, extraer el enlace y el remitente y, si procede, enviarlo a INCIBE-CERT con sus cabeceras.
Pídele también que no intente arreglarlo por su cuenta —borrar correos o archivos, reiniciar el equipo, desinstalar programas— hasta que se lo indique quien gestione el incidente.
Paso 2: identifica qué hizo y qué hacer primero en cada caso
No todos los phishing son igual de graves. Lo que hizo el empleado decide por dónde empezar:
| Qué hizo el empleado | Gravedad | Qué hacer primero |
|---|---|---|
| Solo abrió el correo | Baja | Reportarlo sin borrarlo y buscar a los demás destinatarios (paso 6) |
| Hizo clic en el enlace, sin escribir nada | Baja o media | Anotar la URL, bloquearla y comprobar si se descargó algún archivo |
| Introdujo usuario y contraseña | Alta | Cambiar la contraseña y revocar las sesiones de inmediato (paso 3) |
| Aprobó un aviso de MFA o escribió el código en la web falsa | Muy alta | Dar la cuenta por tomada: revocar sesiones y tokens, revisar métodos MFA y reglas del buzón (paso 3) |
| Concedió permisos a una aplicación | Alta | Revocar el consentimiento y los tokens de esa aplicación (paso 3) |
| Descargó y ejecutó un adjunto | Muy alta | Aislar el equipo de la red sin apagarlo (paso 4) |
| Dio acceso remoto a su equipo por teléfono | Muy alta | Aislar el equipo y tratarlo como una intrusión (paso 4) |
| Hizo una transferencia o cambió una cuenta bancaria | Crítica | Llamar al banco antes que nada y denunciar (paso 5) |
Dos matices. Abrir un correo en un cliente actualizado rara vez compromete el equipo por sí solo, aunque si se cargaron las imágenes el atacante puede saber que el buzón está activo. Y si el empleado no recuerda bien qué hizo, actúa como si hubiera escrito la contraseña: cambiarla y revocar sesiones cuesta poco comparado con quedarse corto.
Si se dan varias situaciones a la vez, empieza por la más grave. Una transferencia ya enviada no espera a que termines de revisar el buzón.
Paso 3: corta el acceso a la cuenta: contraseña, sesiones, MFA y persistencia
Cambiar la contraseña es necesario, pero no suficiente. En los ataques de tipo adversary-in-the-middle (AiTM), la web falsa hace de intermediaria con la página real: el empleado escribe su contraseña y su código MFA, el inicio de sesión funciona y el atacante se queda con la cookie de sesión. Con ella entra sin necesitar ni la contraseña ni el segundo factor, y la sesión sigue viva aunque cambies la contraseña. Microsoft lo dice expresamente en su análisis de estas campañas: hay que revocar las cookies de sesión además de restablecer la contraseña.
En la primera hora:
- Restablece la contraseña y, si la cuenta está claramente comprometida, bloquea temporalmente el inicio de sesión mientras investigas.
- Revoca todas las sesiones y tokens. En Microsoft Entra ID, con la opción de revocar sesiones del usuario o el cmdlet Revoke-MgUserSignInSession. En Google Workspace, restableciendo las cookies de inicio de sesión del usuario desde la consola de administración; suspender la cuenta también las restablece, junto con sus tokens OAuth.
- Revisa los métodos MFA registrados. Con la sesión abierta, el atacante puede añadir su propio teléfono o su app de autenticación para volver cuando quiera. Elimina cualquier método que el empleado no reconozca.
- Elimina las contraseñas de aplicación y revisa las aplicaciones con consentimiento OAuth: una aplicación maliciosa autorizada sigue leyendo el correo aunque cambies la contraseña.
- Revisa las reglas de la bandeja de entrada y los reenvíos. Una regla que mueve o borra los mensajes que contienen factura, pago o transferencia, o que reenvía copias a una dirección externa, es la firma clásica de un fraude en preparación. Revisa también las delegaciones y los permisos sobre el buzón.
- Revisa los dispositivos registrados o sincronizados con la cuenta y retira los que no sean del empleado.
Después, mira en los registros de inicio de sesión desde qué IP y países se accedió, y en los elementos enviados si el atacante escribió a clientes, proveedores o compañeros desde la cuenta. Si lo hizo, hay que avisarles. Las guías enlazadas al final explican cómo buscar reglas de reenvío en Exchange y Gmail y cómo auditar los consentimientos OAuth.
Paso 4: si ejecutó algo o dio acceso remoto, aísla el equipo sin apagarlo
Si el empleado abrió un adjunto que ejecutó algo —una macro, un comprimido con un ejecutable, un acceso directo— o dejó entrar en su equipo a alguien que le llamó haciéndose pasar por soporte técnico, el problema ya no es solo la cuenta: hay que asumir que el equipo está comprometido.
- Desconéctalo de la red, pero no lo apagues. Quita el cable y desactiva la wifi, o usa el aislamiento de red de tu EDR si lo tienes, que mantiene el equipo accesible para el análisis. Apagarlo borra la memoria, donde pueden estar el proceso malicioso, las conexiones activas y datos que solo existen mientras el equipo está encendido.
- No lo reinstales todavía. Formatearlo de inmediato destruye las pruebas que dicen qué se ejecutó, qué se llevó y si ha saltado a otros equipos.
- Cambia desde un equipo limpio las contraseñas de todas las cuentas que se usaban en ese equipo, no solo la del correo: el malware de robo de información suele llevarse también las contraseñas guardadas en el navegador.
- Busca los mismos indicadores en el resto de equipos: el nombre del archivo, su hash o el dominio al que se conecta.
Si hubo acceso remoto por teléfono, identifica qué herramienta se instaló (AnyDesk, TeamViewer, Asistencia rápida de Windows u otra), documenta la sesión antes de desinstalarla y trátala como una intrusión: mientras el empleado miraba la pantalla, el atacante pudo instalar algo más o copiar archivos.
Paso 5: si hubo una transferencia, llama al banco y denuncia
Si el phishing terminó en un pago —una factura con el IBAN cambiado, una transferencia urgente pedida por un falso directivo—, la llamada al banco va por delante de cualquier otra tarea. Cuanto antes lo sepa tu entidad, más opciones hay de que pida a la entidad de destino bloquear o devolver los fondos antes de que salgan de la cuenta.
No hay garantía de recuperarlo. Si la transferencia fue inmediata, el dinero llega en segundos, y una vez abonado la devolución depende de que siga en la cuenta de destino y de la colaboración de la entidad que lo recibió. Por eso cada minuto cuenta.
Ten a mano al llamar:
- Fecha, hora e importe de cada orden.
- IBAN y titular de destino, y la referencia de la operación.
- El correo o mensaje que motivó el pago.
Después, presenta denuncia ante la Policía Nacional, la Guardia Civil o la policía autonómica que corresponda, con toda la documentación; el banco y la aseguradora te la pedirán. Avisa también al proveedor o cliente real cuya identidad se usó: puede que su correo esté comprometido y que otros clientes suyos estén recibiendo el mismo engaño. El fraude del CEO y la suplantación de proveedores tienen su propia guía, enlazada al final.
Paso 6: busca el mismo correo en otros buzones y bórralo
Un phishing rara vez llega a una sola persona. Mientras alguien contiene la cuenta afectada, otra persona debe buscar al resto de destinatarios:
- Localiza todos los ejemplares por remitente, asunto o enlace. En Microsoft 365, con el Explorador de amenazas de Defender for Office 365 (plan 2) o con una búsqueda de contenido de Microsoft Purview y su acción de purga. En Google Workspace, con la herramienta de investigación de seguridad, disponible según la edición contratada.
- Elimínalos de todos los buzones antes de que otra persona haga clic, y comprueba quién más abrió el mensaje o visitó el enlace: cada una de esas personas vuelve al paso 2.
- Bloquea el remitente, el dominio y la URL en el filtro de correo, el proxy o el DNS.
- Avisa a la plantilla con una captura del correo. Un aviso breve y concreto, del tipo «si te ha llegado esto, no lo abras y avisa», funciona mejor que un recordatorio genérico sobre el phishing.
Si el correo suplantaba a una marca, un banco o un organismo, reportarlo ayuda a que se retire la web falsa. Para los casos de fraude, INCIBE-CERT pide el correo sospechoso con sus cabeceras y adjuntos.
Paso 7: evalúa si hay brecha de datos personales y a quién notificar
Un phishing con robo de credenciales es, muy a menudo, también una brecha de datos personales: el buzón de un empleado contiene datos de clientes, proveedores y compañeros. La guía de la AEPD sobre notificación de brechas incluye la suplantación de identidad con compromiso de cuenta entre los ciberincidentes que pueden constituirla. Las obligaciones principales:
- Notificación a la AEPD (artículo 33 del RGPD): sin dilación indebida y, como máximo, en 72 horas desde que tienes constancia de que el incidente ha afectado a datos personales, contando fines de semana y festivos. No hace falta si es improbable que la brecha suponga un riesgo para las personas. Se presenta por el canal de brechas de la sede electrónica de la AEPD y, si a las 72 horas no tienes toda la información, se puede enviar una notificación inicial y completarla después.
- Comunicación a los afectados (artículo 34 del RGPD): cuando la brecha suponga un alto riesgo para sus derechos y libertades, sin dilación indebida y en lenguaje claro.
- Registro interno: el RGPD obliga a documentar todas las brechas, se notifiquen o no, con los hechos, sus efectos y las medidas adoptadas.
La AEPD ofrece dos herramientas gratuitas para estas decisiones: Asesora Brecha, para valorar si hay que notificar, y Comunica-Brecha RGPD, para valorar si hay que comunicarlo a los afectados.
Según quién seas, puede haber otras obligaciones:
- NIS2: la directiva exige a las entidades esenciales e importantes una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en un mes para los incidentes significativos. En España, la ley que la transpone (Ley de Coordinación y Gobernanza de la Ciberseguridad) se aprobó como anteproyecto en enero de 2025, pero a octubre de 2026 no se ha publicado en el BOE, y la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE en julio de 2026. Mientras tanto, quien ya estaba en el ámbito del Real Decreto-ley 12/2018 sigue obligado a notificar a su CSIRT de referencia los incidentes con efectos perturbadores significativos.
- ENS: las entidades del sector público notifican al CCN los incidentes con impacto significativo, y las empresas privadas que les prestan servicios los notifican a INCIBE-CERT, que informa al CCN-CERT (artículo 33 del Real Decreto 311/2022).
Paso 8: pide ayuda y avisa a tu aseguradora
Si no tienes un equipo de seguridad propio, no tienes que resolverlo solo:
- 017, Tu Ayuda en Ciberseguridad de INCIBE: línea gratuita y confidencial que también atiende a empresas y profesionales, de 8:00 a 23:00 todos los días del año. Además del teléfono, por WhatsApp en el 900 116 117 y por Telegram en @INCIBE017.
- INCIBE-CERT: el centro de respuesta a incidentes de referencia para ciudadanos y empresas privadas en España, operativo 24 horas los 7 días. El incidente se le reporta por correo o formulario desde la sección para empresas de la web de INCIBE.
- Tu aseguradora, si tienes ciberseguro: la Ley de Contrato de Seguro da un máximo de siete días para comunicar el siniestro, salvo que la póliza fije un plazo mayor. Antes de contratar a nadie, comprueba si la póliza tiene una línea de atención a incidentes o exige usar su panel de proveedores: un gasto hecho por tu cuenta puede no reembolsarse.
- Un equipo de respuesta a incidentes: si hubo ejecución de código, acceso remoto o indicios de que el atacante se ha movido a otros sistemas, el análisis forense del equipo y de los registros es trabajo de especialistas.
Mientras tanto, guarda todo: el correo original, capturas de lo que vio el empleado, la hora de cada acción que vayas tomando y los registros exportados. Esa cronología te la pedirán el banco, la policía, la aseguradora y, si notificas, la AEPD.
Paso 9: después del incidente, lecciones aprendidas y formación con el caso real
Cuando el incidente esté contenido, dedica una reunión breve a reconstruir lo que pasó sin buscar culpables: cómo llegó el correo, por qué pasó los filtros, cuánto tardó el aviso, qué funcionó en la respuesta y qué se improvisó. De ahí salen las mejoras con más retorno:
- Convierte el correo real en material de formación. Un ejemplo que la plantilla reconoce como propio enseña más que cualquier plantilla genérica. Anonimízalo y no señales a quien cayó.
- MFA resistente al phishing (llaves FIDO2 o passkeys), al menos para las cuentas con más privilegios o más expuestas. Estas credenciales están ligadas al dominio legítimo y no funcionan en una web falsa, que es justo lo que explota el AiTM.
- Acceso condicional que limite los inicios de sesión a dispositivos gestionados o a ubicaciones esperadas.
- Un botón de reporte en el cliente de correo y un canal de aviso que todo el mundo conozca.
- Verificación de cambios de cuenta bancaria por una vía distinta del correo, con una llamada a un teléfono que ya tenías, y la consigna de no ignorar el aviso de verificación del beneficiario que los bancos de la zona euro muestran desde octubre de 2025 cuando el nombre no coincide con el IBAN.
- Alertas ante nuevas reglas de reenvío externo, nuevos métodos MFA y nuevos consentimientos OAuth.
Si el incidente reveló que nadie sabía a quién avisar, eso es lo primero que hay que arreglar: un procedimiento de una página, con nombres y teléfonos, que toda la plantilla conozca antes del próximo correo.
Errores frecuentes que convierten un clic en un incidente grave
La mayoría de los phishing se pueden contener si se actúa rápido y en orden. Estos errores son los que suelen convertir un clic en un problema mayor:
- Castigar al empleado. Consigue que el siguiente no avise, o que avise tarde. El objetivo es acortar el tiempo entre el clic y el aviso, y eso solo ocurre si avisar es seguro.
- Apagar o formatear el equipo antes de analizarlo, con lo que se pierden las pruebas de qué se ejecutó y qué salió.
- Cambiar solo la contraseña. Con una sesión robada o una aplicación autorizada, el atacante sigue dentro.
- No buscar persistencia. Las reglas de reenvío, los métodos MFA añadidos, las aplicaciones OAuth y los dispositivos registrados permiten volver semanas después.
- Mirar solo al empleado que avisó y no buscar a los demás destinatarios del mismo correo.
- Dejar pasar las 72 horas sin valorar si hay brecha de datos personales, o no documentar por qué se decidió no notificar.
- Dar el caso por cerrado sin revisar qué hizo el atacante con la cuenta: correos enviados en su nombre, archivos descargados o compartidos y accesos a otras aplicaciones con inicio de sesión único.
FAQ
¿Basta con cambiar la contraseña si el empleado la escribió en una web falsa?
No. Hay que revocar también las sesiones y los tokens abiertos, porque en los ataques AiTM el atacante se queda con la cookie de sesión y sigue dentro aunque cambies la contraseña. Revisa además los métodos MFA registrados, las reglas del buzón, las aplicaciones autorizadas y los dispositivos asociados a la cuenta.
¿Hay que sancionar al empleado que cayó en el phishing?
Como regla general, castigar un error de buena fe es contraproducente: la próxima persona que caiga tardará más en avisar, y la rapidez del aviso es lo que más limita el daño. Otra cosa es saltarse deliberadamente un procedimiento obligatorio, como el de verificar los cambios de cuenta bancaria, que hay que valorar caso por caso con recursos humanos.
¿Un phishing hay que notificarlo a la AEPD?
Solo si es una brecha de datos personales que puede suponer un riesgo para las personas, algo frecuente cuando el atacante accede a un buzón con datos de clientes o empleados. En ese caso, en un máximo de 72 horas desde que tienes constancia, por la sede electrónica de la AEPD. Si concluyes que no hay que notificar, documenta igualmente la brecha y el motivo de la decisión.
¿Se puede recuperar el dinero de una transferencia hecha por un phishing?
A veces, pero no hay garantía. Depende de lo rápido que avises a tu banco, de si el dinero sigue en la cuenta de destino y de la colaboración de la entidad que lo recibió. Llama al banco en cuanto lo detectes, presenta denuncia y guarda toda la documentación de la operación.
¿Hay que apagar el ordenador si el empleado abrió un adjunto malicioso?
No. Desconéctalo de la red —cable y wifi, o el aislamiento de tu EDR— pero déjalo encendido: apagarlo borra la memoria, donde puede estar la prueba de qué se ejecutó. Tampoco lo formatees hasta que se haya analizado.
¿Qué pasa si el empleado solo abrió el correo y no hizo clic?
El riesgo es bajo: en un cliente de correo actualizado, abrir un mensaje rara vez compromete el equipo por sí solo. Aun así, que lo reporte sin borrarlo, porque sirve para encontrar y eliminar el mismo correo del resto de buzones antes de que otra persona haga clic.
¿A quién puedo pedir ayuda si no tengo equipo de seguridad?
Al 017 de INCIBE (Tu Ayuda en Ciberseguridad), gratuito y confidencial, de 8:00 a 23:00 todos los días, y a INCIBE-CERT, que atiende incidentes de empresas las 24 horas. Si tienes ciberseguro, avisa también a tu aseguradora, y si hubo ejecución de código o acceso remoto, conviene un equipo especializado en respuesta a incidentes.
Servicio relacionado
concienciación en ciberseguridad para empleados, con ejemplos reales de ataques
Contenido relacionado
- Fraude del CEO: cómo detectarlo y qué hacer si ya se ha pagado
- Reglas de reenvío maliciosas en Exchange y Microsoft 365
- Reglas de reenvío y persistencia en Gmail
- Phishing de consentimiento OAuth: cómo detectarlo y revocarlo
- Vishing y deepfakes de voz: suplantación por teléfono con IA
- Qué cubre un seguro de ciberriesgo
- Simulaciones de phishing para empresas
Fuentes
- INCIBE — Reporta tu incidente: canal de INCIBE-CERT para empresas y línea de ayuda 017
- AEPD — Guía para la notificación de brechas de datos personales (versión de junio de 2021)
- Reglamento (UE) 2016/679 (RGPD) — artículos 33 y 34: notificación a la autoridad y comunicación a los afectados
- Microsoft Security — campaña de phishing AiTM y BEC: por qué restablecer la contraseña no basta (enero de 2026)