Thread by @310hkc41b

Vamos a ver si me da tiempo a sacar algo de esto.
Intento hacer hilo analizando los datos en tiempo real (cosa complicada) a medida que salgan datos. Así que paciencia, que hilo puede tardar en aparecer.
(hilo) 🧵

Como se trata de sacar datos, aquí es cosa de "tirar del hilo", como se suele decir. Así que vamos a por los datos. Sabemos que es un SMS, por lo tanto, es un #smishing no un #phishing como he dicho esta mañana, aunque en esencia es lo mismo. Solo cambia el envío.
⬇️

Partimos de un número de teléfono: [phone]
¿Qué sabemos de este teléfono?
Es de España.
Pertenece a la compañía Vodafone.
No tiene WhatsApp.
⬇️

Dicho SMS tiene una URL con certificado:
https(:)//urlshortner.org/MyjSe
Y no por eso es segura, OJO!!!!
Dicha UR es un acortador que nos redirige a:
http(:)//gdsdhfnbxv.temp.swtest.ru/espana/espana
Un dominio Ruso. Curioso ¿verdad? 😉
⬇️

Del destino final sabemos que el servidor es tiene un nginx/1.9.1, pero que se les ha olvidado poner la barra final de la URL y lo redirige a la carpeta correcta.
⬇️

Curiosamente, el contenido HTML de dicha página es algo contradictorio. Se menciona a Apache/2.2.29 sobre S.O. Gentoo y PHP/7.1.33
Podemos hacer caso, o no, podría ser para despistar. Quien sabe. 🤷‍♂️
⬇️

Volvemos a consultar la URL correcta, esta vez poniendo la barra final, y si la carga, pero.... ooooh!!! en Location indica otro dominio: www(.)thelocal(.)es 😑
De momento dejo este dominio a un lado y sigo con este sitio.
⬇️

En la cabecera utilizan "features" del navegador usando permissions-policy.

Un poco raro, pero es que resulta que está cargando la página de www(.)thelocal(.)es
⬇️

Si vamos directamente a www(.)thelocal(.)es aparece la página sin nada aparentemente maliciososo.
⬇️

De hecho, en @virustotal el análisis nos dice que está "limpia".
⬇️

Pero cargando directamente desde el navegador (ojo, con entorno controlado), el propio control de Google nos dice que es un sitio peligroso / malicioso.
Así que si "tiramos p'alante" es bajo nuestra responsabilidad. 😒
⬇️

No voy a tirar "p'alante" todavía. Lo dejo para el final.
Me interesa saber por qué carga otro sitio web antes.
¿Cómo puede ser lo anterior? 🤷‍♂️
Sinceramente, no lo sé. Voy descubriendo cosas sobre la marcha.
Vuelvo a lo obtenido por curl, y sigo escudriñando el código.
⬇️

Insisto, he cargado esto con curl (marcado en rojo).
Pero para engañar carga la url marcada en azul.
Y lo que está en Azul es precisamente lo que carga Maltego al inspeccionar la URL en rojo.
Está hecho aposta para despistar.
⬇️

Me encuentro campos de formulario ocultos con datos codificados en Base64.
⬇️

Pero estos datos, no generan texto o contenido visible fácilmente. Son datos binarios y muy probablemente cifrados y/o comprimidos. Su nivel de entropía es alto, un 7.8.
... y se me "rompió" la VM haciendo algunas pruebas.
Tengo que reiniciar... ☹️
⬇️

Recapitulo:
URL original: https(:)//urlshortner.org/MyjSe
Redirige a: http(:)//gdsdhfnbxv.temp.swtest.ru/espana/espana
Que está movida a: http(:)//gdsdhfnbxv.temp.swtest.ru/espana/espana/
Que a su vez redirige a: https(:)//www.thelocal.es/
⬇️

Hay cierta cosa que me despistaba, y realmente es algo que se me ha pasado por alto y que tienen en cuenta los ciberdelincuentes. Y, es que hay que no hay que subestimarlos, y ellos también toman contramedidas.
⬇️

He pasado por alto, qué curl envía su propio agente, y tras mirar el código que me devolvía al solicitar la URL he visto lo siguiente:
⬇️

Y si, la siguiente cadena:
aHR0cHM6Ly93d3cudGhlbG9jYWwuZXMv
está codificada en Base64 y su resultado es:
https(:)//www.thelocal.es/
¿Qué hacía esta cadena ahí? 😒
⬇️

Pero la que hay debajo, que también está en Base64:
Y3VybC83Ljc0LjA=
Al decodificar me devuelve:
curl/7.74.0
Que es precisamente la versión de curl que yo estoy usando en este momento.
⬇️

Y la de debajo: R0VU
Es: GET
Que es el método usado.
Así que si el sitio web devuelve esto, significa que en el servidor se analiza el agente de usuario, y en función de este pueden cambiar el contenido que devuelven.
⬇️

Así que haré una nueva petición incluyendo otro agente de usuario.
⬇️

Y efectivamente, esta vez el resultado es diferente.
⬇️

¡¡¡Pero OJO!!!
Que aquí esto da un giro y después de pasar por la URL maliciosa, da un salto a la web de @bancosantander
⬇️

Aquí en medio hay algo turbio, que evidentemente tiene que ser digno de analizar. 😒
⬇️

Y si, lo he repetido varias veces para estar seguro. Sí, hace el salto a la web oficial de @bancosantander.
¿Qué hace en medio? De momento para mí es incógnita.
⬇️

Por si acaso, he desactivado el seguir las redirecciones y he ido cargando manualmente cada una de las URLs por si se enviaba algo más.
⬇️

Pero no. Cada carga es una redirección hasta llegar finalmente a la web de @bancosantander
⬇️

¿Habrán los ciberdelincuentes desactivado su operación de #phishing?
O es que, ¿se les ha estropeado la página para capturar los logins de los usuarios?
⬇️

Y, ¿por qué reenviar directamente a la web oficial del banco? ¿No quieren que pierdan visitas?
En el caso de hacer un login previo para captar datos, tiene sentido. Pero ¿sin pedir login?
⬇️

Podría especular, en que, quizás desde la IP o rango de IP que estoy haciendo las peticiones hayan puesto una excepción para evitar ser analizados. Y simplemente me redirigen a la web oficial.
⬇️

Así que, para acabar (porque no dispongo de más tiempo). Corto por lo sano y pruebo la URL en ANY.RUN, a ver que me dice.
Y muestra la web de www(.)thelocal(.)es 🤦‍♂️
app.any.run/tasks/c2c6e700…

Lo irónico de todo, es que esta mañana, cuando hice la foto y puse la captura en un tuit de este #smishing, yo había puesto la palabra "ELABORADISIMO" en tono irónico precisamente, pero ha resultado ser justamente esto.
⬇️

Finalizo el hilo, quedándome con la incógnita, aunque sigo pensando que @bancosantander debería de tomar cartas en el asunto y no aceptar accesos a su web procedentes de esa redirección.
(fin) 🔚

Bueno, bueno, bueno... va a ser la primera vez que "reabro" un hilo, o hago añadido, tras darme cuenta de que ha pasado en el final de este hilo. Pero solo voy a dejar un par de anotaciones y lo dejo.
Así que continuo el hilo.
⬇️⬇️

La clave está en el "agente de usuario". Yo mismo he dado la explicación antes. Resulta que el #smishing está pensado para que funcione ÚNICA Y EXCLUSIVAMENTE desde un dispositivo móvil. Si se accede desde un navegador de PC, no funciona.
⬇️

Así que si desde curl se usa un agente de usuario de Android, por ejemplo, funcionará y devolverá lo que esperamos que devuelva.
"Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
⬇️

Hago nueva petición con agente de usuario cambiado.
⬇️

Y obtenemos el resultado de la página que realmente recibiría un dispositivo móvil.
⬇️

Y ahora sí. Cierro definitivamente este hilo.
(fin) 🔚