El procedimiento
En caso de que se detecte un esquema de phishing, todo el sitio web de phishing se envía a la víctima como un archivo adjunto de HTML y luego se ejecuta localmente en el navegador.
Mientras se investigaba esta actividad de phishing, el Security Lab de Hornetsecurity descubrió una táctica interesante en uno de los formularios web de phishing utilizados. En uno de estos formularios, la primera contraseña introducida por el usuario siempre se rechazaba por ser incorrecta y sólo se aceptaba la segunda contraseña.
Es probable que esto explique un método que se les ocurrió a algunos usuarios para protegerse contra el phishing. Algunos usuarios creen que los sitios web de phishing siempre aceptarán cualquier contraseña. Por tanto, puede detectar un sitio web de phishing introduciendo una contraseña incorrecta. Un sitio web de phishing aceptará la contraseña incorrecta, mientras que el sitio legítimo la rechazará por ser incorrecta. Sin embargo, esta suposición es incorrecta y el Security Lab de Hornetsecurity explicará el por qué en este artículo.
Antecedentes
El phishing enviado a las víctimas como un archivo adjunto de correo electrónico a través de código HTML de la página web infectada, no es nada nuevo [1]. El esquema general es que la víctima recibe un correo electrónico con un documento HTML adjunto.
Aquí podemos ver un ejemplo reciente de tal intento de phishing contra un banco:
En el correo electrónico se le dice al usuario que el perfil de usuario debe ser actualizado, de lo contrario los servicios del banco no podrán ser utilizados por más tiempo.
Cuando el usuario abre el archivo adjunto, un formulario le pide las credenciales del usuario o, en este caso, toda una serie de información privada y confidencial:
El documento es incluso útil y comprueba (localmente a través de las características del HTML5) si la información que el usuario ha introducido tiene un formato válido, por ejemplo, el correo electrónico contiene un símbolo @, etc.:
Una vez que la entrada del usuario fue validada localmente, se emite una solicitud HTTP POST que envía la información introducida a un servidor remoto:
Este esquema es una gran manera de evitar que su sitio web de phishing sea incluido en una lista negra, ya que no hay ninguna página web de phishing visible online que un proveedor de hosting pueda eliminar. Conseguir que un sitio web sea prohibido porque recibe solicitudes HTTP POST es difícil de transmitir a un proveedor de hosting o al propietario de un sitio web comprometido.
Recientemente el Security Lab de Hornetsecurity encontró un nuevo e interesante giro a este esquema de larga duración de tales anexos de phishing HTML que pretenden ser de una de las principales empresas de logística de contenedores integrados y de la cadena de suministro.
Análisis
La actividad de phishing de la que forma parte este interesante esquema se mantiene ininterrumpidamente durante un mes, y de forma diferente probablemente durante años:
El hecho de que se envíen más correos electrónicos durante los días laborables indicaría que esta actividad está dirigida a las empresas:
Aunque el lenguaje de los correos electrónicos de phishing es exclusivamente en inglés, los correos se envían predominantemente a empresas alemanas, estadounidenses y británicas:
Se concede que la distribución por países está ligeramente sesgada por la base de clientes de Hornetsecurity, ya que Hornetsecurity es líder del mercado en la región DACH.
Como nota interesante, las redes desde las que se envían estos correos electrónicos son las siguientes:
Estos son los dueños de los 7 AS con el mayor volumen de correos electrónicos enviados :
| Volúmen | ASN | Dueño ASN |
| 5450 | 199653 | ARUBAFR-AS, FR |
| 5425 | 6697 | BELPAK-AS BELPAK, BY |
| 3300 | 266772 | TRIMOTION S.R.L., AR |
| 1450 | 8374 | PLUSNET Plus network operator in Poland, PL |
| 1375 | 15704 | XTRA TELECOM S.A., ES |
| 1275 | 54290 | HOSTWINDS, US |
| 1225 | 1221 | ASN-TELSTRA Telstra Corporation Ltd, AU |
Doble petición de contraseña al usuario
Aunque la mayoría de los documentos de phishing observados siguen el esquema anteriormente descrito – salvo por el hecho de pedir al usuario sólo una contraseña y tener la dirección de correo electrónico del usuario ya cumplimentada previamente en el documento- algunos otros documentos de phishing de esta serie, sin embargo, vienen con un giro.
Al abrir el documento de phishing se pide al usuario que introduzca la contraseña para poder ver previamente algunos documentos de envío:
Independientemente de la contraseña que se introduzca, al usuario se le presenta inmediatamente otro formulario emergente de contraseña que afirma que la introducida es incorrecta:
Esto se hace probablemente en un intento de evitar que los usuarios más avispados intenten primero con una contraseña inventada – en caso de que sea un phishing – y sólo introduzcan su contraseña real cuando una contraseña falsa no les permite acceder.
Pero sólo la última contraseña introducida se envía al servidor remoto:
Por último, pero no menos importante, el usuario es redirigido al servicio de alojamiento de imágenes Imgur y se le presenta una imagen de los documentos de envío:
Obviamente, esos documentos ilustrados son tan falsos como el propio correo electrónico de phishing.
Conclusión y reparación
Este ejemplo muestra que el truco propuesto por algunos usuarios para protegerse contra el phishing introduciendo siempre primero una contraseña falsa y sólo después de que esa contraseña haya sido rechazada introducir la contraseña correcta, no funciona. La lógica detrás de este truco parece ser que la mayoría de los formularios de phishing aceptarán cualquier contraseña. Por lo tanto, si un sistema rechaza una contraseña incorrecta, debe ser legítima, de lo contrario, ¿cómo sabría que la contraseña es incorrecta? Pero como este caso ha demostrado, un formulario de phishing puede simplemente rechazar su contraseña también. De hecho, podría rechazar todas las contraseñas y enviar todos los intentos al atacante con la esperanza de que la víctima entregue todas las contraseñas mientras intenta acceder al formulario de contraseñas falsas.
La solución no es tan simple. Dado que la página web de phishing se carga localmente en el navegador de la víctima, las listas negras como la de Safebrowsing de Google, no avisan al usuario de que se ha abierto una página web de phishing. Otra cosa es el mecanismo de exfiltración. La única solicitud HTTP POST se envía a un sitio web de WordPress probablemente comprometido, lo que hace difícil de descubrir en una red ocupada y porque no hay un sitio web de phishing visible online también es difícil de investigar por un analista de redes.
La forma más segura de protegerse contra estos archivos adjuntos de páginas web HTML de phishing, es no permitir que entren en el buzón del usuario. Por ejemplo, los sofisticados mecanismos de análisis de Hornetsecurity Spam and Malware Protection detectan esos correos electrónicos en las primeras instancias de filtrado y bloquean esos correos electrónicos de phishing antes de que puedan ser entregados a un buzón.
