Hoy, como aficionado al análisis forense digital (la parte puramente IT, sin entrar demasiado en lo legal), analizaré de forma didáctica el caso ficticio “Lionel Hutz papers” planteado en UCAM CTF, incidiendo en los procesos de resolución empleados y las conclusiones sobre la naturaleza del ataque. Espero que os parezca interesante.
En primer lugar, dos handicaps autoimpuestos:
- A diferencia de un ejercicio de IR (respuesta rápida ante incidentes), la evidencia la trataré siempre en frío.
- Por tanto, se usará exclusivamente el disco, like old school (que da nombre al post), sin tocar la RAM y mucho menos levantar la VM aislada para monitorizar su actividad.
En segundo lugar, al ser un ejercicio enmarcado en el formato CTF, responderemos de forma indirecta a cuestiones que bien pueden ser interesantes, o bien podrían ser irrelevantes o no concluyentes durante la elaboración de las conclusiones y por tanto en según que casos reales no se habría ni siquiera planteado. Dicho esto, ¡vamos al lío!
URL: https://retoforense.dorvack.com/challenges
VM VMware: HASH256 – 0315A2399446F484796B7C198D6AD0A4BAF35DDC6FD4D35FC17161A4B154F986.
VM VirtualBox: HASH256 – no se ofrece.
Preámbulo
Para meternos en el contexto del ejercicio, supondremos que una compañera del SOC de Madrid interrogó a los implicados y nos ha dejado una información inicial del caso, aquí la resumo:
- Se ha producido un robo de datos en el bufete de abogados de Lionel.
- Lionel solo tiene un ordenador en el bufete, del cual me han pasado un .rar que contiene una copia bit a bit de la imagen de la máquina virtual que estaba corriendo.
- Hay sospechas de que se pudo haber clonado el disco.
- Lionel afirma que el día 10 de abril empezó a notar comportamientos anómalos en su PC. Ese día entró a trabajar a las 9:00h y él mismo cerró su despacho a las 19:30h. Fue unos días antes de que se produjera la filtración.
- Nadie del bufete de abogados tiene una buena política de contraseñas.
- Lionel dispone de un WordPress en bufetehutz[.]com alojado en su PC.
- Lionel, que no tiene conocimientos de IT, me pide ayuda para incriminar al ladrón y demostrar/justificar su autoría (¿vector de entrada/salida? ¿IPs/dominios empleados? ¿IOCs conocidos?).
Whoops! Parece el Cluedo, todos los sospechosos en una misma casa (PC), un solo culpable (usuario) y una víctima (empresa).
Las primeras impresiones son importantes
Descargamos la imagen de la evidencia con extensión .vmkd (formato VMware), comprobamos el hash SHA-256 con ‘certutil.exe’ y la descomprimimos en un SSD. Como consejo: los forenses en discos SATA son la muerte a pellizcos; un SSD te dará la vida, la inversión merece totalmente la pena.
Visualizamos el árbol de directorios del disco de la evidencia importando la imagen en modo solo lectura con la herramienta FTK Imager de AccessData (una alternativa es autopsy). Se observa un disco de 30 GB asignados, dividido en 2 particiones:
- Información del sistema (100MB)
- Datos (29.9GB).
Me gusta empezar preguntándole a la evidencia nombre, apellidos, DNI, edad, dónde vive y algún dato más… cumpliendo siempre con el RGPD, ojo ;). La configuración del sistema operativo se guarda en un 99% dentro del registro de Windows, así que tan solo tenemos que saber la rama, clave y valor correctos. Los ficheros más relevantes que lo conforman se encuentran en las rutas ‘%SystemRoot%\System32\config‘ y ‘%UserProfile%\’ (la raíz del espacio de trabajo de cada usuario). Algunos de ellos:
Abrimos el fichero de registro CONFIG con el visor Registry Viewer de AccessData (una alternativa es Registry Explorer), que navegando al valor ‘HKLM\Config\ControlSet001\Control\ComputerName\ComputerName’ nos dice que el equipo se llama Bufete_01.
Para saber el nombre del producto y su versión/build, consultamos la clave ‘HKLM\Software\Microsoft\Windows NT\CurrentVersion’ donde se observa que es un Windows 7 Professional, Service Pack 1 con compilación 7601 (valores ‘ProductName’, ‘CSDVersion’ y ‘CurrentBuildNumber’ respectivamente).
Para saber de qué producto se trata nos bastaría también con el valor ‘CurrentVersion’, 6.1, que se puede consultar su equivalencia en la propia documentación de Windows.
Para saber la edad del sistema operativo podemos pensar en la fecha en la que se instaló por primera vez en el equipo. Podemos navegar al valor ‘HKLM\Software\Microsoft\Windows NT\CurrentVersion\InstallDate’, que contiene el dato ‘0x5caa45f2 (1554662898)’ en formato unix/epoch. Se convierte fácilmente con algún lenguaje de scripting, véase Python, obteniendo la fecha 19.04.07 20:48:18 (UTC/GTM). Un domingo por la tarde de formateo, instalación y configuraciones, nada mal el plan.
Hola Bufete_01, encantado! :)
Inicios del sistema y sesiones de usuario
Para identificar los usuarios registrados en el equipo analizamos el fichero de registro SAM con la herramienta MiTec WRR (Windows Registery Recovery), que extrae tanto los nombres, como su SID, fechas del último logon y cambios de contraseña, entre otros. Lionel, Jeff y Secretaria deben ser usuarios asociados a empleados de la empresa, mientras que Administrador, Invitado, HomeGroupUser$ se generan por defecto en Windows.
Para obtener las fechas de logon/logoff de cada usuario es fundamental entender que este tipo de acciones Windows las trata como eventos, por tanto, si se han producido y existen, se encontrarán principalmente en la ruta ‘%SystemRoot%\System32\Winevt\logs’, de la que nos copiaremos la carpeta entera porque seguro que usaremos muchos de sus ficheros en algún momento.
Además, todos los eventos que se guardan en un registro de Windows tienen un identificador que se denomina EventID. A priori, cada evento tiene un EventID propio, algo que se cumple (casi) siempre.
En este caso, usando la herramienta Event Viewer instalada por defecto en Windows, identificamos en el fichero ‘Microsoft-Windows-User Profile Service%4Operational.evtx’ los 6 eventos que se generan en cada logon(4)/logoff(2) de usuario. Por ejemplo, podemos observar que el último usuario en hacer logoff en el equipo fue Lionel.
Como muchas de las acciones que se producen en Windows pueden ser verificadas de más de una forma. Para el ejemplo del último logoff, tenemos varias alternativas. Una de ellas se encuentra en ‘System.evtx’, con EventID 1074.
Otra de las más conocidas está en ‘Security.evtx’ con EventID 4624 (logon), 4647 (empieza el logoff) y 4634 (logoff). Se puede encontrar información sobre los tipos de logon aquí. Dejo unos apuntes de varios EventID a tener controlados:
En total se producen 10 logons: Lionel (7), Secretaria (2) y Jeff (1).
Al igual que las sesiones, podemos saber de varias formas las fechas en las que el sistema operativo se inició/apagó. Una de ellas es con el fichero `System.evtx` filtrando por los EventID 12 (inicio) y 13 (cierre).
Otra alternativa es con el EventID 6006, que indica el cierre del propio servicio EventLog. Como se aprecia en el timeline anterior, el último logoff que se produce el día 7 de Abril sucede a las 20:18:29, mientras que el cierre del servicio *EventLog* se produce a las 20:18:18 (11 segundos antes). Podemos afirmar que trackear logs que con alta probabilidad suceden de forma secuencial es una buena práctica.
Si queremos saber el último apagado del equipo, lo podemos coger del valor ‘ShutdownTime’ de la clave del registro ‘HKLM\System\CurrentControlSet\Control\Windows’.
Pero lo tendremos en formato FILETIME para convertirlo podemos usar algún conversor online o cualquier lenguaje de scripting, como Powershell.
Clonado de discos
Nos ha dicho que se ha podido producir un clonado de discos. Con FTK Imager montamos la imagen de la evidencia (en modo solo lectura) y validamos el número de serie de ambas particiones verificando que son 049B-BB18 para la partición de datos y FC97-FE61 para el sistema.
Seguridad de las credenciales LSASS
Nuestra compañera del SOC nos ha comunicado que tenían una mala política de contraseñas, veamos si rascamos algo.
Con la herramienta Mimikatz instalada en la VM de la evidencia se podrían extraer los hashes y contraseñas locales/dominio almacenados en memoria, incluso podríamos volcar la memoria reservada por el proceso ‘lsass.exe’, pero hemos dicho que solo usaremos el disco.
En el fichero de registro SAM, en la clave ‘\Domains\Account\Users\{usuario}’ que corresponde a un usuario, contiene dos valores (F, V) con los cuales se puede obtener el hash de su contraseña si se cruzan con la clave SysKey almacenada en SYSTEM. Para facilitar este proceso, usaremos algo más de botón gordo.
Existen varias formas: la que vamos a emplear consiste en copiar los ficheros del registro SAM y SYSTEM en una distro de Linux (por ejemplo SIFT Workstation) e instalar la herramienta samdump2 para que extraiga de forma automática los hashes correctos de las claves de cada usuario.
Con Mimikatz también podemos obtener los hashes (sin incumplir los handicaps) actuando sobre los mismos ficheros SAM y SYSTEM. Nos descargamos la herramienta con los componentes de seguridad de Windows desactivados (bajo vuestra responsabilidad) y lo lanzamos desde un terminal con privilegios de administrador. Se muestran los hashes obtenidos.
Una vez tenemos los hashes, con JohnTheRipper (una alternativa es hashcat) en modo incremental, los crackeamos resultando contraseñas de tan solo 4 dígitos en cuestión de segundos, que justamente coinciden con las de nuestros 3 usuarios.
Si nos fijamos en el dato del que partimos, contraseñas débiles, es probable que ya estén por Internet las claves asociadas a los hashes. Algunas webs que podemos consultar son:
- https://hashkiller.co.uk/Cracker
- https://www.cmd5.org/
- https://crackstation.net/
- http://cracker.offensive-security.com/
- https://hashes.org/check.php
En la primera web ya encontramos lo que nos interesa: sin duda la opción más rápida y por la que debería haber empezado.
Hasta aquí la primera parte de este post. La próxima semana publicaremos la segunda parte. Estate atento para no perderte el desenlace del análisis.
