Phishing

Un ataque de phishing tiene tres partes: un pretexto que hace que actuar parezca razonable, un canal que lo transporta, y un mecanismo que convierte la acción de la víctima en acceso.

El pretexto se construye con contexto, y el contexto es barato. Cuentas depositadas en el registro, ofertas de empleo, perfiles sociales, logotipos de proveedores en una web, una respuesta automática de ausencia, la lista de asistentes de un congreso. Un mensaje sobre una factura de un proveedor con el que de verdad trabajas, enviado mientras tu responsable financiero está visiblemente fuera, no es un truco en el que nadie deba avergonzarse de caer.

El mecanismo es lo que cambió, y es la parte que la mayoría de la formación de concienciación no ha alcanzado. El modelo antiguo cosechaba una contraseña en una página falsa y la usaba más tarde, y eso lo cerró en buena medida la autenticación multifactor. El modelo actual es un proxy inverso: el sitio del atacante retransmite la página de inicio de sesión real en tiempo real, así que la víctima ve el sitio auténtico porque es el sitio auténtico. Escribe la contraseña, completa el segundo factor en el servicio real, la autenticación tiene éxito, y el atacante se queda con la cookie de sesión resultante. No se rompió nada. El factor funcionó. La sesión se tomó después de que funcionara.

A partir de ahí el atacante no necesita volver a iniciar sesión. Registra su propio método de autenticación, crea una regla de buzón para esconder las respuestas y mira a qué llega la cuenta. En un tenant corporativo eso suele ser correo, ficheros y un directorio que le dice adónde ir después.

Hay variantes más silenciosas que evitan las credenciales por completo: convencer a un usuario de que apruebe la petición de acceso de una aplicación, con lo que el atacante se queda con un token en vez de con una contraseña, y abusar de los flujos de autorización de dispositivo, de forma que la víctima teclea un código legítimo en una página legítima. Las dos producen un acceso duradero y ninguna se parece a una página de phishing.

El fallo de la organización es medir lo que no toca. La tasa de clic es fácil de recoger y no dice casi nada, porque con un buen pretexto la tasa se acerca a todo el mundo. Los números que importan son cuánta gente lo reportó, con qué rapidez llegó el primer aviso, y a qué llegó el atacante con el primer acierto. Una organización con una tasa de clic alta y un tiempo de aviso de dos minutos está mucho mejor que una con una tasa de clic baja y ningún canal para avisar.

El segundo fallo es tomarse la concienciación como el control. La formación reduce los casos fáciles y no hace a la gente inmune a un pretexto bien documentado, ni se le debe pedir eso. Culpar a un usuario por un mensaje redactado específicamente para su puesto y para su semana es injusto y además inútil desde el punto de vista operativo, porque hunde los avisos, que son el control que sí funciona.

El tercero es la distancia entre la seguridad del correo y la seguridad de la identidad. La autenticación de correo con DMARC impide que suplanten tu dominio y no hace nada contra un dominio parecido, contra el buzón real de un proveedor comprometido o contra un mensaje que llega por chat. Mientras tanto el ataque aterriza en el plano de la identidad, donde los controles que importan son la vinculación de la sesión, el cumplimiento del dispositivo y el tipo de factor.

El cuarto es lo que pasa después del clic, que es donde se decide el incidente. Si una sesión comprometida puede registrar un método de autenticación nuevo en silencio, crear reglas de reenvío y leer el histórico entero del buzón, un solo mensaje con éxito es una brecha grave. Si las acciones sensibles exigen una comprobación fresca ligada al origen, ese mismo mensaje es una alerta.

La palabra cubre una familia, y las variedades se diferencian en el canal y en el objetivo más que en el principio.

Dos de estas merecen atención aparte. El fraude del CEO no lleva muchas veces ningún enlace malicioso: se compromete el buzón real de un proveedor y un hilo de factura auténtico continúa con otros datos bancarios. Y el quishing existe porque un código QR lleva a la víctima a un teléfono personal, que normalmente no tiene ninguna de las protecciones corporativas que sí tiene el equipo de escritorio.

Presentar la tasa de clic como la métrica del programa. Mide el pretexto, no la organización. La tasa de aviso y el tiempo hasta el primer aviso miden la organización.

Castigar a quien hace clic. Reduce los avisos, que son el único control que escala.

Dar por hecho que la MFA lo resuelve. Resuelve la cosecha de credenciales. No resuelve una sesión retransmitida salvo que el factor esté ligado al origen.

Probar con un pretexto flojo. Un mensaje genérico con errores evidentes produce un número cómodo y ninguna información. Una simulación realista es incómoda y útil.

Centrarse solo en el correo. Las llamadas de voz al servicio de soporte tienen una tasa de éxito alta en nuestros proyectos, y son la vía que la mayoría de las organizaciones no ha probado nunca.

Reduce lo que vale un mensaje con éxito, porque no vas a reducir a cero la tasa de acierto. Pasa a factores ligados al origen para que un inicio de sesión retransmitido no dé nada, aplica acceso condicional para que la sesión quede ligada a un dispositivo conforme, y exige una comprobación fresca antes de añadir un método de autenticación, de cambiar un dato de pago o de crear una regla de reenvío de correo. Esos tres cambios convierten la mayor parte del phishing con éxito en un suceso contenido.

Haz que avisar sea la acción más fácil disponible. Un botón de aviso de un clic, un acuse de recibo y una respuesta visible. La métrica a mejorar es el tiempo entre la primera entrega y el primer aviso, porque es lo que determina si se puede proteger al resto de los destinatarios.

Arregla la higiene técnica que quita las variantes baratas: autenticación de correo publicada e impuesta, marcado de remitente externo, y vigilancia de los registros de dominios parecidos a tu marca. Y después acuerda una regla de verificación fuera de banda para los cambios de pago que se aplique sin excepciones, porque las excepciones son exactamente lo que el pretexto está diseñado para provocar.

Para la detección, las señales más fuertes están en el registro de identidad y no en la pasarela de correo: un método de autenticación registrado poco después de un inicio de sesión desde una ubicación inusual, una regla nueva de reenvío de correo, un token emitido para un cliente que el usuario no ha usado nunca, o un inicio de sesión desde la dirección de un proveedor de alojamiento. Las sesiones de adversary in the middle se ven ahí cuando son invisibles en todo lo demás.

Un proyecto de phishing informa de lo que pasó después del clic, no solo de cuántos hicieron clic. Registramos el pretexto, la entrega, la proporción que interactuó, la proporción que avisó, el tiempo hasta el primer aviso, y después el resultado técnico: qué sesión obtuvimos, a qué llegó, y qué control nos paró o dejó de pararnos.

La evidencia lleva marca de tiempo para que el cliente pueda encontrar las entradas correspondientes en sus propios registros, y las credenciales no se registran nunca. Cuando hemos obtenido una sesión retransmitiendo un inicio de sesión, lo decimos claramente, porque si no el equipo del cliente dará por hecho que su factor estaba mal configurado cuando estaba funcionando correctamente.

La severidad se escribe contra el alcance. Un usuario que entrega credenciales de una cuenta sin privilegios es una cosa. Una sesión en un buzón que aprueba pagos, en un tenant donde se puede dar de alta un factor nuevo en silencio, es otra.

Ejecutar ese ejercicio de forma realista, y medir la respuesta en vez del clic, es para lo que sirve un ejercicio controlado de ingeniería social.

¿La MFA detiene el phishing? Detiene la versión que cosecha contraseñas. No detiene una retransmisión en tiempo real del inicio de sesión, que captura la sesión después de que el factor funcione. Solo resisten a eso los factores ligados al origen, como WebAuthn, porque la firma va atada al sitio real.

¿Cuál es la diferencia entre phishing y spear phishing? Volumen e investigación. El phishing se manda de forma amplia con un pretexto genérico. El spear phishing apunta a una persona concreta con detalles sacados de su puesto, de sus proyectos y de su calendario, y su tasa de acierto es mucho más alta.

¿Debemos castigar a los empleados que hacen clic? No. Hunde los avisos, y avisar es el control que limita el daño. Mide la respuesta de la organización, haz que avisar sea trivial, y reserva las consecuencias para quien desatienda repetidamente un procedimiento de verificación, no para quien caiga en un pretexto bien construido.

¿Qué es el quishing? Phishing entregado como código QR. Importa porque lleva a la víctima a un teléfono personal, fuera del filtrado de correo, del navegador gestionado y de la política de dispositivo que protegen el escritorio corporativo.