Las señales de phishing que enseñabas ya no existen

La diapositiva de los cursos de formación ha sido la misma durante una década: busca errores gramaticales, busca "Estimado cliente" y pasa el ratón sobre el enlace para comprobar adónde apunta en realidad. Esas eran heurísticas razonables porque describían el aspecto real del phishing masivo.

Lo que realmente describían era el coste. Un mal inglés delataba a un atacante que trabajaba por volumen en un segundo idioma. Un saludo genérico significaba una única plantilla enviada a cien mil direcciones. Un enlace sospechoso implicaba infraestructura que el atacante debía alojar en alguna parte. Cada señal visible era síntoma de operar de forma barata a gran escala.

Ese coste se derrumbó y las señales desaparecieron con él, por lo que la formación que las enseña genera ahora una falsa confianza en lugar de cautela.

El problema

Considera el mensaje que un responsable de seguridad podría recibir hoy. Está escrito en un inglés fluido. Hace referencia a la auditoría de seguimiento de ISO 27001 programada para el próximo mes, porque ese dato es público en un directorio de certificación. Coincide con el registro habitual del remitente, porque esa persona escribe en público y hay texto de sobra para imitarla. No contiene archivos adjuntos ni enlaces. Plantea una pregunta razonable sobre a qué entidad fiscal debe emitirse una factura.

No hay nada sobre lo que pasar el cursor ni nada que detonar en un entorno aislado (sandbox). El dominio tiene una semana de antigüedad y, por lo demás, está limpio. Cada señal de la presentación de formación está ausente, y la petición en sí misma constituye el ataque.

La persona que lo recibió no falló en la formación. La aprobó, pero la formación estaba evaluando lo incorrecto.

Por qué es diferente con la IA

La economía del ataque se invirtió, y el Internet Crime Complaint Center del FBI lo reflejó en un único par de cifras. En 2025, las denuncias por phishing y suplantación cayeron de 193,407 a 191,561, cerca de un uno por ciento. Las pérdidas reportadas en esa categoría aumentaron de $70,013,036 a $215,843,126, un incremento del 208 por ciento [1]. Hubo menos denuncias y aproximadamente el triple de dinero sustraído.

Esa divergencia muestra con claridad el paso del volumen a la precisión. Una sola campaña dirigida a un millón de personas se transformó en mil campañas dirigidas a mil personas cada una, y la calidad por objetivo que antes se reservaba al fraude de alto valor pasó a ser asequible en todas partes. En el mismo informe, el compromiso de correo electrónico corporativo (BEC) representó $3,046,598,558 en 24,768 denuncias, con una media cercana a los $123,000 por incidente [1].

Tres factores específicos cambiaron para quienes defienden los sistemas.

El lenguaje dejó de ser una prueba. La fluidez nunca fue una propiedad de seguridad. Era una aproximación al esfuerzo del atacante, y esa referencia se quebró.

El contexto pasó a ser barato. Crear un perfil recopilando información del programa de una conferencia, un registro de certificaciones y publicaciones públicas solía requerir una hora de trabajo de un operador, por lo que se reservaba para objetivos de gran valor. Ahora es solo un paso dentro de un pipeline automatizado.

La carga útil (payload) se volvió opcional. Si el objetivo es un cambio en los datos bancarios o una aprobación, no hace falta malware. Los controles técnicos que analizan adjuntos y verifican la reputación de las URL siguen funcionando igual de bien que antes; sencillamente, no se encuentran en la ruta del ataque.

Un cuarto cambio recibe menos atención porque no tiene que ver con el mensaje inicial. La gestión de respuestas solía ser un cuello de botella: un primer correo convincente sirve de poco si el atacante no puede sostener la conversación posterior, en el tono adecuado, en la zona horaria correcta y sobre detalles que desconoce. Esa limitación prácticamente desapareció. Un hilo de mensajes puede prolongarse durante días sin que el atacante sea fluido, esté despierto o conozca tus procesos de facturación. Los consejos basados en la idea de que interactuar con un remitente sospechoso terminará delatándolo han dejado de ser ciertos sin que nadie lo advirtiera.

Lo que de verdad funciona

Deja de pedir a los usuarios que juzguen la redacción y empieza por controles que se sostengan sin importar el texto.

Verifica la solicitud en lugar del mensaje. Establece una regla estricta: cualquier petición para modificar datos de pago, transferir fondos o facilitar credenciales debe verificarse mediante un canal acordado de antemano, utilizando un número que ya figure en los registros internos y nunca el número incluido en el mensaje. La norma funciona tanto si la solicitud llega como prosa impecable o como un disparate evidente, y por eso resiste el paso del tiempo.

Haz que las credenciales no tengan valor para el atacante. La autenticación resistente al phishing elimina el valor de una contraseña robada. Esto es determinista y no se degrada a medida que mejora la redacción del atacante.

Capacita sobre la petición. Sustituye las señales de estilo por una lista breve de solicitudes que siempre disparen un protocolo de verificación. Esa lista es estable, fácil de enseñar y no requiere actualización cada vez que mejoran las herramientas del atacante.

Combina señales que el lector no puede ver: la antigüedad del dominio, si has mantenido correspondencia previa con esa dirección, si los registros de autenticación concuerdan y si la redacción se desvía del historial habitual de ese remitente. Estas tareas corresponden a los sistemas. Despliégalas primero donde un falso positivo resulte barato, en mensajes reportados por los usuarios y después de la entrega, antes de bloquear nada en línea.

El orden de este último punto tiene consecuencias operativas reales. Evaluar el correo entrante con un modelo conlleva un coste en falsos positivos medido en operaciones comerciales legítimas bloqueadas, por lo que debe ganarse su lugar antes de activarse de golpe. Comienza donde un fallo no cueste nada: mensajes que los usuarios ya han reportado, donde el modelo clasifica una cola en lugar de tomar decisiones sobre la entrega. Pasa después a acciones posteriores a la entrega, donde un mensaje puede retirarse a posteriori y el daño de una decisión equivocada se resuelva con una disculpa en vez de una venta perdida. Solo después de haber medido la tasa de falsos positivos frente al tráfico real debe bloquearse algo en línea.

El mismo orden se aplica a toda la lista, situando primero los controles deterministas y la detección probabilística al final. Conviene tener un modelo que puntúe la intencionalidad, pero también es la capa que se degrada sin previo aviso conforme el atacante perfecciona sus métodos, motivo por el cual debe colocarse detrás de los controles que no fallan.

Lo que no funciona

Actualizar la lista de señales no sirve de nada. Algunos consejos han pasado a recomendar "desconfiar de los mensajes redactados demasiado bien". Eso no aporta nada útil y enseña a los empleados a desconfiar de compañeros competentes.

El phishing simulado es una métrica deficiente. Las tasas de clics en simulaciones miden la capacidad del personal para reconocer simulaciones. Las campañas construidas con la misma biblioteca de plantillas que el atacante ya abandonó están midiendo una amenaza del pasado.

Esperar a que el filtro lo detecte rara vez funciona. Un mensaje sin enlaces ni archivos adjuntos, enviado desde un dominio sin historial previo y con registros de autenticación correctos, ofrece muy poco margen al filtrado de contenido. Los controles que frenan esto residen en el proceso de pago, fuera de la ruta del correo.

Culpar al destinatario resulta contraproducente. Cuando un mensaje supera cada una de las comprobaciones que se enseñó a aplicar a un empleado, la formación falló y el empleado hizo exactamente lo que se le indicó. Tratarlo de otra manera desincentiva los avisos, que constituyen la única señal humana que aún funciona bien.

Detectar "texto generado por IA" es un callejón sin salida. Los clasificadores que afirman identificar prosa generada por máquinas no son fiables en ninguna de las dos direcciones, y de todos modos responden a la pregunta equivocada. Gran cantidad de correos comerciales legítimos se redactan con la ayuda de un modelo. Que un mensaje haya sido generado por IA no indica en absoluto si la petición que contiene es fraudulenta.

Por dónde empezar

• Pon la regla de verificación por escrito y aplícala a cambios de pago, transferencias de fondos y solicitudes de credenciales. Limítala a una página, define el canal alternativo y especifica que el número de teléfono debe proceder de tus propios registros.
• Audita las excepciones a esa regla. La urgencia y la jerarquía son las dos excepciones que más se aprovechan, y son justo las que imita el atacante.
• Adopta autenticación resistente al phishing para cualquier usuario con permisos para aprobar pagos o acceder a entornos de producción.
• Reescribe el material de concienciación centrándote en las solicitudes y no en las señales de estilo. El contenido será más breve y dejará de quedar obsoleto.
• Cambia la métrica del phishing. El volumen de correos bloqueados mide únicamente lo que se ha vuelto más barato; añade a su lado las pérdidas por incidente y el tiempo medio de notificación.
• Facilita la notificación para que no tenga fricción ni consecuencias negativas. Cuando las señales visibles desaparecen, la inquietud de una persona es una señal real y, a menudo, la única alerta temprana. Cualquier factor que haga sentir la notificación como admitir un error la anulará por completo.

La parte incómoda es que la señal detectable restante se ha desplazado en gran medida fuera del mensaje hacia el contexto que lo rodea: quién es esa contraparte, si has tratado antes con ella y si la petición encaja en la relación comercial. Las personas bajo presión de tiempo están en mala posición para evaluar eso, mientras que un proceso estructurado responde mucho mejor.

Fuentes

1. 2025 Internet Crime Report, FBI Internet Crime Complaint Center: https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf