El phishing intenta que una persona entregue credenciales, abra un archivo o apruebe una operación creyendo que trata con una fuente legítima. En una empresa, el daño puede empezar en un buzón y terminar en una cuenta de administración, un cambio de datos bancarios o el acceso a documentos internos.
El riesgo no se reduce a reconocer mensajes mal escritos. Los ataques pueden imitar proveedores, compañeros y procesos habituales, por lo que las decisiones sensibles necesitan una verificación independiente.
Cómo se convierte un mensaje en un incidente
Un correo puede dirigir a una página que imita el inicio de sesión, pedir un código, solicitar una transferencia o cambiar instrucciones de pago. También puede inducir a abrir un documento o responder con información de clientes. El objetivo es aprovechar la confianza y la urgencia, no demostrar una habilidad técnica concreta.
La persona que recibe el mensaje no siempre puede saber si el remitente visible es auténtico. Por eso conviene evitar que un único correo autorice cambios de cuenta, pagos o entrega de información sensible.
Procesos que necesitan doble comprobación
Define una segunda vía para verificar cambios de proveedor, cuentas bancarias, restablecimientos y accesos privilegiados. Usa un número ya conocido, un portal interno o una aprobación separada, no los datos de contacto incluidos en el mensaje sospechoso.
La separación de funciones ayuda: quien recibe una petición no tiene que ser la única persona que modifica el registro. El proceso puede ser más lento, pero reduce el impacto de una suplantación convincente.
Contraseñas, MFA y gestores
Un gestor de contraseñas puede asociar credenciales al dominio legítimo y dificultar que se introduzcan en una página parecida. MFA reduce el valor de una contraseña robada, aunque códigos y notificaciones aún pueden ser solicitados mediante engaño. Las llaves resistentes al phishing ofrecen una protección diferente al verificar el origen del sitio.
Revisa sesiones abiertas, métodos de recuperación y dispositivos autorizados después de una sospecha. Cambiar la contraseña no basta si el atacante conserva una sesión o controla el correo de recuperación.
Correo y dominio como controles complementarios
SPF, DKIM y DMARC ayudan a que los receptores evalúen mensajes que pretenden usar un dominio corporativo. Su configuración puede reducir suplantaciones directas, pero no impide que se registre un dominio parecido ni que una cuenta legítima sea comprometida. La política debe desplegarse gradualmente para no bloquear correo válido.
Los filtros de correo y las alertas son señales, no sustitutos de la verificación humana. Un mensaje que pasa una comprobación técnica aún puede contener una petición fraudulenta enviada desde una cuenta comprometida.
Qué hacer después de hacer clic
Informa pronto al equipo responsable, cambia credenciales desde un dispositivo confiable, revoca sesiones y conserva el mensaje y sus cabeceras para el análisis. Si se aprobó un pago o se compartieron datos, avisa también al área correspondiente para intentar contener la operación. Ocultar el incidente retrasa la respuesta.
Crear una respuesta que no dependa de la memoria
La formación funciona mejor con ejemplos de procesos reales y un canal claro para preguntar sin penalización. Define qué solicitudes requieren llamada, quién autoriza cambios y cómo se registra una excepción. La autenticación de correo, MFA y la atención de los usuarios reducen riesgos diferentes; ninguno garantiza por sí solo que toda suplantación sea detenida.
Señales que merecen verificación
Una urgencia inusual, un cambio de cuenta bancaria, una petición fuera del canal habitual o un enlace que conduce a un dominio parecido justifican una comprobación independiente. La gramática perfecta no prueba legitimidad y un error evidente tampoco es necesario para que exista una suplantación.
Los procedimientos deben cubrir llamadas, mensajes internos y proveedores conocidos. Verificar desde el mismo hilo comprometido puede confirmar al atacante en lugar de confirmar la petición.
Limitar el impacto de una cuenta comprometida
Separa permisos, restringe acceso a información sensible y revisa sesiones y reglas de reenvío del correo. Una cuenta no debería poder autorizar por sí sola un pago y cambiar el contacto de recuperación. Las alertas sobre nuevos dispositivos o reglas automáticas pueden revelar una intrusión aunque nadie haya notado el mensaje inicial.
Tras un incidente, conserva cabeceras, URLs y tiempos, pero evita redistribuir enlaces peligrosos sin control. La respuesta debe informar al equipo adecuado y valorar también cuentas que recibieron el mismo mensaje.
Medir la respuesta sin culpar al usuario
Registra el tiempo entre el aviso y la contención, las cuentas afectadas y los procesos que fallaron. El objetivo de una simulación es descubrir si el canal de reporte funciona y si la verificación está definida, no penalizar a quien dudó ante un mensaje cuidadosamente construido.
Después de cada incidente, actualiza contactos, ejemplos y controles. La respuesta debe incluir también a proveedores que gestionan correo, pagos o identidad, porque una cadena de confianza puede ampliar el impacto.
El canal de reporte también es un control
Un botón o dirección de reporte visible permite avisar antes de que varias personas respondan al mismo mensaje. El equipo receptor debe poder retirar enlaces, revisar reglas de correo y comunicar el alcance sin reenviar contenido peligroso. Medir el tiempo de aviso ayuda a mejorar el procedimiento, no a convertir la respuesta en una competición.