30 Jul Cazando gamusinos en Internet I
Todos recibimos correos de spam. Casi todos ellos son molestos e inofensivos, pero a veces llega alguno que puede llegar a hacer bastante daño. En este artículo voy a analizar uno de esos malotes que me llamó la atención por un par de pequeños detalles. A veces esos detalles son los que despiertan la curiosidad y una vez empiezas a tirar del hilo, te soprendes dónde acabas. Cómo no, cazando gamusinos. O fantasmas… digitales. Este es un ejemplo de Análisis Forense a un correo. Partiendo de unos datos iniciales muy básicos, analizaremos el recorrido que ha realizado este correo por la red. Y al tirar del hilo, veremos cómo las herramientas OSINT se convierten en utilidades indispensables si queremos entender porqué suceden las cosas.
Empecemos por el correo de marras. Por cuestiones obvias, he ocultado el dominio utilizado por el malote para enviar el email, así como los datos personales. La vulnerabilidad aún persiste y lejos de mi intención que alguien más se aproveche de ello.
Nuestro análisis forense a un correo
Lo primero que me llama la atención es el asunto: Confirmación de pago. ¡Pero si yo no he pagado nada! ¿Quién envía esto? Y veo que es una agencia de viajes, por su dominio (que tú no verás porque lo he tachado). Aparentemente es un correo legítimo. Si ha llegado a mi buzón, con todos los filtros antispam y comprobaciones SPF de registros de correo, al menos es legítimo. ¿Será un error?
Yo tengo configurado mi correo para que no muestre los cuerpos de mensajes en formato html, y me separe las partes del mensaje por cabeceras, cuerpo y adjuntos. Es una buena práctica que recomiendo. Porque lo segundo que me salta a la nariz son esos dos adjuntos de factura que llevan la extensión .jar
Lo primero es preguntar a la santa wikipedia qué es eso de .jar Y la respuesta es muy interesante:
«Un archivo JAR (por sus siglas en inglés, Java ARchive) es un tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java. Las siglas están deliberadamente escogidas para que coincidan con la palabra inglesa ‘jar’ (tarro). Los archivos JAR están comprimidos con el formato ZIP y cambiada su extensión a .jar.»
Es decir, nos han endosado 2 archivos ejecutables en Java. Obvio decir que ni mirarlos… de momento.
Lo siguiente, como dicen en mi pueblo, ¿y tú, de quién eres?. Para saber algo más de su origen, abrimos las cabeceras del mensaje. En Horde (el webmail que uso), zimbra, thunderbird y los correos electrónicos «decentes» la opción de ver las cabeceras del mensaje son obvias y están a mano. En mi caso, sólo tengo que clicar en «Ver Origen».
Si eres de los que utilizan Outlook, lo tienes más complicado, pero también se puede. Tienes que ir a propiedades del mensaje con el botón derecho, y en una de las opciones aparece en un cajetín de texto bastante incómodo para leer. Por eso no uso Outlook. Si algún lector sabe el modo de hacerlo mejor, la sección de comentarios a vuestra disposición 🙂
Una vez abierto el origen del mensaje, aparece un texto con muchas lineas raras. Lo que debemos hacer es buscar donde aparece el texto Subject (asunto) y a partir de ahí, vamos a ir leyendo hacia arriba para averiguar qué camino ha recorrido este correo, fijándonos en las lineas que comienzan por Received (recibido):
Received: from [210.195.177.178] ([210.195.177.178]) by webmail.***.com (Horde Framework) with HTTP; Mon, 23 Jul 2018 13:10:03 +0200 Date: Mon, 23 Jul 2018 13:10:03 +0200 Message-ID: <20180723131003.Horde.TGFVm4vOEWNYruNY7YjVZRW@webmail.***.com> From: aas907c@***.com To: Subject: =?utf-8?b?Q29uZmlybWFjacOzbg==?= pago User-Agent: Horde Application Framework 5
¿A qué conclusiones llegamos con el análisis forense al correo?
De aquí sacamos que la cuenta de correo origen es aas907c@***.com Si es un correo legítimo del gerente de ventas de esa empresa, qué nombre de cuenta tan raro, ¿no? También vemos que la ip de origen es 210.195.177.178 (como es del malote como veremos después, ni la ocultamos). Y además se envía desde un servidor webmail del dominio origen ***.com y además la aplicación webmail es Horde. Justo debajo de la linea Subject vemos User-Agent, que es el indicador de la aplicación de correo cliente de quien nos envía el mensaje. También vemos que es Horde.
Me sigue mosqueando además que mi servidor de correo y el filtrado SPF se haya comido crudito el correo. Veamos las cabeceras SPF:
Received-SPF: pass (lincl1123.zinetik.com: domain of ***.com designates 188.B.C.D as permitted sender) client-ip=188.B.C.D; envelope-from=aas907c@***.com; helo=setentayocho101.XXX.com; Received: from setentayocho101.XXX.com (localhost.localdomain [127.0.0.1]) by setentayocho101.XXX.com (Postfix) with ESMTPSA id 187B5C3236; Mon, 23 Jul 2018 13:10:04 +0200 (CEST)
Vemos que el siguiente salto del correo ha sido al servidor setentayocho101.XXX.com (dominio ocultado) que está con la ip local 127.0.0.1 y, anteriormente, el registro SPF de mi servidor comprueba que es un servidor de correo legítimo para el dominio ***.com del emisor del correo y responde a la IP (ocultada) 188.B.C.D. Esto se pone interesante.
Lo siguiente que vamos a hacer es averiguar algo más sobre el dominio ***.com, el dominio setentayocho101.XXX.com que dice ser la IP 188.B.C.D, y la IP del usuario de webmail 210.195.177.178. Para esto me gusta consultar le web de http://cqcounter.com/whois/ que da información bastante fiable y sin poner demasiadas pegas, más que un captcha. Esto es lo que obtenemos:
Dominio ***.com (el dominio emisor del correo):
Vemos que la IP asociada a este dominio coincide con la del servidor setentayocho101.XXX.com, por lo que sabemos que el dominio ***.com está alojado en este servidor. Y en este servidor existe un servicio de correo y un webmail activo.
IP del usuario de webmail 210.195.177.178 :
Vemos que esta IP es de Malasia. Dudo que el gerente conecte desde Malasia para enviarnos dos archivos adjuntos con extensión .jar
Ahora, la duda que me surge es: ¿realmente el servidor de correo del dominio ***.com es el mismo donde está alojado su hosting?
Vamos a consultar los registros DNS del dominio ***.com desde la utilidad nslookup de Windows:
nslookup> set type=MX > ***.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: ***.com MX preference = 10, mail exchanger = mx01.sp***.com ***.com MX preference = 20, mail exchanger = mx02.sp***.com > set type=A > mx01.sp***.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre: mx01.sp***.com Addresses: 92.B.C.D 92.B.C.E > set type=A > ***.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre: ***.com Address: 188.B.C.D > www.***.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre: ***.com Address: 188.B.C.D Aliases: www.***.com > webmail.***.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre:***.com Address: 188.B.C.D Aliases: webmail.***.com
¿Qué vemos con todo esto?
Observamos lo siguiente:
- El dominio ***.com está alojado en el servidor setentayocho101.XXX.com
- La IP del servidor setentayocho101.XXX.com es la 188.B.C.D y coincide en las consultas DNS con la resolución de los nombres www.***.com y webmail.***.com
- El correo del emisor pertenece al dominio ***.com
- El registro MX de correo para el dominio ***.com apunta a otro hosting, que está en el dominio sp***.com y sus ips son 92.B.C.D y 92.B.C.E
Ahora bien, con estos datos ¿qué conclusiones podemos sacar? Por lo visto la IP del servidor que envía el correo NO es la que el DNS tiene designado como servidor de correo. Sin embargo, el DNS apunta a que tiene configurado un servidor web y un servicio de webmail basado en Horde. Y quien hace uso de ese webmail lo hace desde Kuala Lumpur. Además, este spam es reciente porque mi filtrado de correo basado en las listas RBL no da positivo para la ip 188.B.C.D, tal como muestra el query a spamhaus.org: https://www.spamhaus.org/query/ip/188.B.C.D
Por último vamos a consultar en virustotal.com qué eran esos adjuntos .jar que nos enviaban, no vaya a ser que efectivamnete sean los pagos realizados 🙂
Descargamos con mucho cuidado los archivos .jar y realizamos la consulta a virustotal en su página web https://www.virustotal.com/es/:
Y efectivamente comprobamos que el regalito viene acompañado con 3 preciosos troyanos Java.
De este modo hemos confirmado que el correo era falso, que se envía desde una IP de un servidor medio-legítimo al que se accede desde Malasia, y que lleva adjuntos 3 troyanos.
Sin embargo, hay algunas cosas que me siguen intrigando. La cuenta de envío del correo, pese a pertenecer al dominio ***.com y haberse enviado desde el propio servidor webmail de dicho dominio, no tiene pinta de ser muy real. Y los registros DNS del correo apuntan a que los servidores de correo son otros diferentes al que aloja el servicio web. ¿Por qué entonces está activo el servicio webmail? ¿Por qué los registros SPF no indican que sean los servidores MX los únicos autorizados a enviar correos? ¿Quién ha creado la cuenta aas907c@***.com?
Si hubieran colado algún script .js o .php en la web, el campo X-MAILER diría algo así como /wp-content/plugins/mi-super-plugin/pp.php donde pp.php es un script (me he inventado el nombre) que permite el reenvío de correos. Es algo habitual en sitios web comprometidos hechos con WordPress y similares, que están mal o escasamente mantenidos y protegidos. Pero aquí el caso es otro, alguien incia sesión webmail con una cuenta de ese dominio. ¿Qué puede haber pasado?
Como la curiosidad pica, y más si se es inquieto, vamos a averiguar hasta donde podamos y la Ley nos permita, qué ha podido suceder. Un poco de Osint y nmap ayudarán a la tarea. Pero eso, en la próxima entrega.
Mientras tanto me surge otra duda. Si esta cuenta «no oficial» del dominio ***.com existe y no ha sido detectado por spamhaus ni otros filtros, sería interesante poner sobre aviso a los titulares. Pero nunca sin mi abogado de por medio. El caso es que mi abogado dice que ni de coña, así que… si alguien se anima, bienvenido.
Feliz DFIR
No Comments