Servidor de ficheros – Nivel básico
1. ¿Cuál es el número de serie del volumen de la única partición de la imagen de disco del servidor de ficheros?
El número de serie del volumen es un valor hexadecimal que se genera cuando se crea el sistema de ficheros. La documentación de Microsoft nos dice que para sistemas de ficheros NTFS lo tenemos en la posición 0x48 del BPB (Bios Parameter Block), que es parte del sector de arranque. Este sector lo tenemos en el disco en el $boot (en el raiz del disco). Montamos el disco con FTK Imager y accedemos al valor hexadecimal:
Ahí tenemos el valor: 652496C0. Sin embargo, al introducirlo en la web del reto no acepta la solución como válida, así que algo estamos haciendo mal. Después de darle muchas vueltas, pensé: “Esta es una pregunta básica, no me jodas. Tiene que haber una forma muy sencilla de obtener la respuesta”. Y tanto. Si tenemos la imagen montada con FTK Imager, se ve como otra unidad cualquiera del sistema, así que nada nos impide usar el método live de saber el VSN de un sistema de ficheros: el comando vol.
He perdid… digo invertido cerca de una hora de mi vida aprendiendo la estructura interna de NTFS (miremos las cosas por el lado bueno :D). Lo curioso es que el valor era el correcto solo que estaba al revés (y he buscado un buen rato el motivo hasta que he caído en lo de los Little Endian/Big Endian).
Referencias:
- https://www.digital-detective.net/documents/Volume%20Serial%20Numbers.pdf
- https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781134(v=ws.10)
* Respuesta: C0962465
2. ¿Cuál es el nombre del examinador que realizó la imagen forense?
Para esas cosas están los logs de adquisición (el sitio donde se ponen los hashes y esas cosas que nadie piensa que necesita hasta que un día alguien se olvida de calcularlos y ocurren desgracias).
* Respuesta: Professor Frink
3. ¿Quién borró todos los eventos del log de seguridad?
Volvemos a la carga con los logs. En este caso parece que el log de Security no ha sido borrado (no encontramos el EventID de “Log cleared”), pero sí que vemos una barbaridad de eventos con EventID 4625 (37989 para ser exactos), que indican un error al intentar iniciar sesión.
Parece que alguien ha intentado llenar el log para que se sobreescriban los eventos más antiguos (la configuración por defecto en Windows), porque si filtramos ese EventID tan solo nos quedan 117 eventos, siendo el más antiguo del 07/08/2018. Y por lo que se puede entrever de algunas preguntas anteriores el incidente de seguridad pudo empezar a finales de Julio.
Sin embargo, no esperaban a la Inquisic… digo a nuestra astucia como forenses. Cada vez que se inicia una sesión, independientemente de si es en local o en remoto, se carga el perfil de usuario del mismo. Esta acción deja un registro en el log Microsoft-Windows-User Profile Service%4Operational.evtx, que podemos consultar con facilidad ya que el número de eventos es siempre muchísimo más reducido (y los atacantes cuando se dedican a cubrir sus huellas siempre atacan los logs de Security y de Terminal Services, pero nadie hace caso al pobrecito User Profile … para nuestra fortuna).
Este resultado tiene definitivamente mejor pinta, porque el 31/Jul tenemos un log del usuario mpowers a hora intempestivas. No lograríamos una condena a muerte con una evidencia tan circunstancial, pero es la respuesta correcta.
* Respuesta: mpowers
4. ¿Qué hostname tiene el equipo?
Esta no tiene mucho misterio. Toda la configuración de Windows está guardada en el registro, así que es algo tan simple como acceder a:
Esta vez lo vamos a hacer más sencillo todavía con el truco de “Cargar Subarbol”. Abrimos RegEdit, pinchamos en HKEY_LOCAL_MACHINE y seleccionamos “Archivo–>Cargar subarbol”. Buscamos el SYSTEM del servidor HR y lo cargamos como SYS_HR… y ya podemos navegar sin problemas.
* Respuesta: WIN-M5327EF98B9
5. ¿Cuándo se apagó el equipo por última vez? [formato: Month/Day/Year Hour:Minute:Second in 24 hour timr 1/1/2018 14:01:01]
Otra pregunta de registro. Si no has cerrado todavía el RegEdit, es tan sencillo como ir a:
El problema es que es un dato binario, y hay que interpretarlo. Como lo del RegEdit lo habíamos hecho para enseñar nuevas formas de hacer las cosas, vamos a volvernos al RegistryExplorer, que tiene una característica maravillosa llamada “Data Interpreter”. Accedemos a la clave y activamos el intérprete de datos y obtenemos el resultado sin problemas… F***! !¿Cómo que incorrecta?! Espera, que es un reto hecho por americanos, y hacen las cosas a su manera, incluyendo las fechas. Colocamos los meses y los días como a ELLOS les gusta, y obtenemos la respuesta correcta.
* Respuesta: 7/26/2018 10:16:16
6. ¿Cuál es el Current Build number de Windows del servidor de ficheros?
Seguimos con el registro de Windows. Una búsqueda rápida nos indica la clave del registro donde se esconde nuestra información:
Referencia:
- https://tommynation.com/how-to-determine-windows-edition/
* Respuesta: 7601
7. ¿Qué user id tenia mpowers?
Los identificadores de usuario (UserID) se guardan en la SAM del equipo, otra clave de registro (recuerda: toda la configuración está en el registro). 30 segundos de RegRipper nos dan el resultado:
* Respuesta: 1000
8. ¿Cuál fue el último programa que ejecutó Max Powers a través del interface gráfico?
Aquí lo más sencillo sería mirar el Prefetch, pero este equipo no gasta de eso porque es un Server (lo comprobamos en la captura de pantalla de la respuesta anterior, es un Windows Server 2008 R2 Enterprise). Nos va a tocar tirar del UserAssist (que guarda el registro de los últimos ejecutables lanzados por el usuario).
Un poco de RegRipper con el NTUSER.dat del usuario, y aquí tenemos el resultado:
* Respuesta: sub-win-x64_104.148.109.124_5682_3262.exe
9. ¿Cuánto fue la última vez que Max Powers abrió el fichero projections.zip? [format: UTC TIme Day/Month/year Hour:Minute:Sec in 24 hour time 1/1/2018 15:20:11]
Esta parecía sencilla pero vamos a comprobar con rapidez que tiene su mordiente. En un caso normal sería cuestión de recuperar la MFT, convertirla a .csv y tirar un grep para encontrar los tiempos MAC del fichero projections.zip.
Sin embargo, no hay rastro del projections.zip en la MFT. Analizamos los MRU del usuario y tampoco hay nada. Si recordamos la pregunta 19, alguien está cubriendo deliberadamente sus huellas, así que es posible que nos encontremos con temas de anti-forense.
Nos toca de nuevo trabajar con las shadow copies. Levantamos de nuevo la VM con SIFT y copiamos el fichero con la imagen en formato .e01, para luego identificar la partición NTFS y buscar las posibles shadow copies.
Calculamos el offset con el principio de la partición y el tamaño en bytes de cada sector:
206848 * 512 = 105906176
Y buscamos las shadow copies con vshadowinfo, encontrando premio:
Ahora es cuestión de montar la shadow copy con vshadowmount (recuerda que hay que montar primero el VSS para luego montar el sistema de ficheros):
Lo más sencillo es buscar directamente el projections.zip… pero no tenemos suerte:
Así que nos tocará volver a sacar los MRU del usuario de la shadow copy y analizarlos. Copiamos el NTUSER.dat y lo montamos en Windows para poder lanzar el plugin recentdocs de RegRipper:
Ya tenemos al parecer nuestra fecha. Pero como hay dos .zip, y no tengo del todo claro si esa fecha de última escritura es la correcta o no. Para convencerme del todo vamos a abrir el NTUSER.dat con Registry Explorer y de esta forma acceder a los valores en bruto, localizados en:
Confirmamos la respuesta, convertimos al formato deseado por el CTF, y recogemos nuestros merecidos puntos.
* Respuesta: 8/7/2018 20:09:15
10. ¿Cuántos clusters tiene la partición?
Rebuscando un poco por Internet encontramos el comando fsutil, que lanzado desde un terminal elevado (o sea, con privilegios de administrador, no subidos en una escalera) nos da la respuesta
La convertimos de binario a entero con la web que hemos usado en otras preguntas, y a correr.
* Respuesta: 13081343
Servidor de ficheros – Nivel avanzado
11. ¿A dónde nos lleva el directorio \VSS?
Si lo buscamos en nuestra unidad montada, encontramos que C:\vss es un acceso directo. Si hacemos uso de la imagen montada con FTK Imager encontramos el directorio correcto al que accede.
Si lo adecentamos un poco obtenemos la respuesta.
* Respuesta: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
12. ¿Cuándo fue creado el Volume Shadow Copy 1? [formato UTC TIme 1/1/2018 13:11:11 Month/Day/Year 24 Hour Time]
Esta respuesta nos la da vshadowinfo, que como lo habíamos usado en una pregunta anterior nos da la respuesta automática:
Y que la plataforma no acepta. WTF? Revisamos correctamente el puñetero formato de fechas y comprobamos que es el correcto. Parece que o bien la herramienta nos ha traicionado vilmente o que el reto no está correctamente ejecutado.
Necesitamos una segunda opinión, así que nos descargamos una versión de prueba de ForensicsExplorer, que tiene una funcionalidad de análisis de shadow copies:
Forensic Explorer también nos da la razón, por lo que tiene que ser un problema de los creadores del reto. Nuestro trabajo aquí está hecho (aunque nos quedemos sin puntos)
* Respuesta: 8/7/2018 20:13:26
13. ¿Desde dónde inició sesion Max Powers?
La respuesta está en los logs de Terminal Server (Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx). Por ahora parece que el incidente ha debido de tener lugar el 7 de Agosto sobre las 20:00h, por lo que nos centramos en lo que ocurre en nuestro Visor de Eventos sobre las 22:00h (recuerda el UTC+2). Y nos cuesta muy poco encontrar un inicio de sesión sospechoso:
* Respuesta: 74.118.138.195
14. ¿Qué programa fue usado para borrar los artefactos forenses?
En este caso volvemos a los resultados del UserAssist, que nos dan las últimas ejecuciones del usuario mpowers. Repasándolas con cuidado encontramos una que suena bastante sospechosa:
Una búsqueda rápida en Google nos confirma que Privazer es una herramienta para eliminar las acciones de un usuario en un sistema. No del todo perfecta al parecer.
* Respuesta: PrivaZer.exe
15. ¿Cuál es el nombre del fichero .zip que contiene el directorio M4Projects?
Por ahora parece que la cuenta del usuario mpowers es la responsable del incidente, así que nos centramos en buscar en sus alrededores sin éxito. Probamos a buscar en los UserAssist sin fortuna, y la MFT no nos da información adicional. Parece que el Privazer.exe nos ha jorobado pero bien, así que vamos a tener que volver a las shadow copies.
Sin embargo, en una pregunta anterior teníamos un listado de los .zip que nos va a venir estupendamente:
Si contrastamos con la imagen de disco montada en el FTK, ninguno de los .zip que encontramos en el directorio del usuario mpowers. Si hacemos un listado del contenido de los .zip con el comando “unzip –l”, encontramos que ambos tienen el mismo contenido:
Podemos contrastar con FTK el contenido encontrado de la carpeta M4Projects y confirmar que en efecto ambos contienen el resultado deseado:
Pito, pito gorgorito… probamos FileServerShare.zip y nos da el resultado deseado.
* Respuesta: FileServerShare.zip
16. ¿Qué host ha sido empleado para exfiltrar los datos?
Antes de encontrar el destino tenemos que encontrar el programa empleado para la exfiltración. Seguimos con la teoría de que el atacante solo ha tenido acceso a la cuenta del usuario mpowers, así que solamente tiene privilegios de usuario. Esta hipótesis nos dice que el atacante solo ha podido emplear lo que hay en la cuenta de usuario y lo que hay instalado en el sistema, lo que nos ayuda a acotar el análisis.
En el directorio del usuario mpowers tenemos estas aplicaciones sospechosas:
El segundo fichero es F-Response (firmado digitalmente), por lo que lo podemos descartar. El primero es muy interesante, en primer lugar porque aparece en VT (aunque mirando las fechas posiblemente sea algún otro participante el que lo haya subido):
y que hasta tenemos ejecución en Hybrid-Analysis:
Pero si lo miramos con más detalle, este ejecutable estaba entre la info que parece que el atacante se ha llevado, así que lo lógico es que este ejecutable estuviera ya en el equipo y fuera el objetivo (por lo que lo podemos descartar)
Descartando ambos programas, vamos a ver lo que tenemos instalado en el sistema: Google Chrome e Internet Explorer. Es momento de un poquito de BrowsingHistoryView… que también nos falla. Privazer nos está complicando la existencia lo suyo, pero ya que tenemos montadas las shadow copies vamos a extraer el historial de navegación del usuario mpowers.
Si abrimos el historial con (recuerda que es una BD SQLite) con un visor adecuado y rebuscamos un poco, encontramos nuestro premio:
* Respuesta: www.dropbox.com
17. ¿Cuál es la URL a la que se exfiltraron los datos?
¡Combo 2×1! Con la resolución de la pregunta anterior tenemos gratis esta.
* Respuesta: https://www.dropbox.com/request/51bpm0D7zHjRbfvuqGzt
18. ¿Qué hives del registro se llevó el atacante? (por favor, lístalas en orden alfabético con un espacio entre cada nombre)
Vamos a permitirnos un pequeño salto hacia delante en el tiempo. En una pregunta del nivel siguiente tenemos que recuperar unos ficheros del equipo, y resultan ser SAM y SYSTEM. Dado que esos ficheros son parte del modus operandi del atacante, es más que probable que haya repetido en este equipo lo que ha hecho en el anterior… y tenemos razón.
* Respuesta: SAM SYSTEM
19. ¿Qué herramienta ha sido empleada para borrar el Journal USN?
Seamos vagos por una vez. Si tenemos una herramienta de limpieza de rastros ejecutada en el sistema y culpable de una cosa, echémosle la culpa de todo. Posiblemente, también mató a Kennedy y es la culpable del calentamiento global… ¿por qué no?
Sorprendentemente, funciona. Bueno, no tan sorprendentemente porque si revisamos la documentación de Privazer lo pone bien clarito :D
* Respuesta: Privazer.exe
20. ¿Qué servicio empleó el atacante para acceder al sistema?
Si nos vamos a los distintos logs de servicios, lo único que encontramos es que el usuario mpowers cargó su perfil el 31/Jul a las 0:43 horas (UTC+2). El log de conexiones de Terminal Server está frito, pero el que guarda información de las sesiones locales no: Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational, y nos indica que a la misma hora el usuario mpowers se ha conectado de forma remota al equipo.
Terminal Services no es una respuesta válida, ya que nos piden el nombre real del servicio: rdp
* Respuesta: rdp
Servidor de ficheros – Nivel experto
21. ¿Qué programa ha extraído el fichero Mnemosyne.sys?
Más sabe el diablo por viejo que por diablo dice el refrán. Y en este caso, si has trabajado con F-Response sabrás que es el nombre del driver que necesita para acceder a la memoria física del equipo.
* Respuesta: F-Response
22. ¿Qué directorio fue eliminado de forma segura?
Si alguien usó algún programa de borrado, tiene que haber dejado algún resto en el $usrjnl, así que lanzamos de nuevo el NTFS Log Tracker. Ups. Nos hemos olvidado de que PrivaZer.exe se lo había merendado hace 3 preguntas.
Un poco de exploración de los directorios con FTK Imager, y asumiendo que el usuario no tenía privilegios de administrador, nos permite localizar un directorio sospechoso
Parece que alguien le ha dado fuerte a ese directorio. Podemos confirmarlo haciendo un grep de la MFT que ya teníamos convertida y viendo qué nos dice al respecto
Fechas aleatorizadas, tamaño 0, ni rastro de las extensiones… parece un trabajo ruidoso pero concienzudo.
* Respuesta: C:\M4Projects\project_0x02
23. ¿Quién solicitó esta exfiltración de datos?
Esta la sabemos por el gen “vieja del visillo” de mirar todo lo que se pueda en un incidente. En una pregunta anterior nos hemos hecho con una URL de Dropbox. Si accedemos a ella tenemos claro quién ha sido el culpable:
* Respuesta: Sideshow Bob
24. ¿Cuál es la dirección de correo de la persona que subió los datos a Dropbox?
El cuerpo nos pide localizar todas las direcciones de correo existentes en el equipo, algo que podemos hacer con bulk_extractor bajo la imagen cargada en Linux.
Y lo dejamos suelto por todo el disco duro. Un par de horas más tarde tenemos un listado de direcciones de correo encontradas en el sistema: 215854. Va a ser que necesitamos una herramienta un poco más fina.
Abrimos Autopsy y cargamos la imagen con el plugin de búsqueda por palabras (que tiene una específica para encontrar direcciones de correo):
Eso sí, le va a costar lo suyo (concretamente, casi 12h porque tengo el SSD lleno con otras cosas y tirar de SATA es una eternidad). Al día siguiente tenemos café y resultados, por lo que podemos empezar a realizar búsquedas por palabras.
Dado que Dropbox está implicado en la exfiltración de datos, vamos a asumir que si existe una dirección de correo tiene que estar “cerca” en el disco, por lo que vamos a realizar una búsqueda en toda la imagen por www.dropbox.com:
Tan solo 11 hits, esto puede prometer. Y si lo analizamos con un poco más de detalle, nos damos cuenta de que el número 8 tiene exactamente la petición HTTP al Dropbox empleado por el atacante:
Vamos a ver si somos capaces de encontrar alguna dirección de correo dentro de los resultados. El trabajo va a ser un poco farragoso ya que tenemos el fichero tiene 9819 páginas según Autopsy, aunque solo 12 de ellas tienen hits con Dropbox. Dado que no podemos buscar dentro del submenú de Autopsy toca copiar en un fichero de texto y tirar de grep:
- P29: nope
- P30: nope
- P34: nope
- P37: nope
- P38: nope
- P39: nope
- P41: nope
- P43: nope
- P50: nope
- P168: snakepleskin@gmail.com
- P170: nope
- P1018: nope
- P1060: nope
Suena MUY interesante. Realizamos una verificación realizando otra búsqueda por palabras con la cadena “snakepleskin” y comprobamos que tenemos un hit más, justo al lado de la petición de Dropbox:
No es como encontrar el arma del crimen en un asesinato, pero es suficiente como para que la pongamos como solución. Y funciona, así que nos llevamos los puntos y la satisfacción de terminar el reto (esta es la pregunta que más me ha costado, pero sienta BIEN el tener todas las respuestas).
* Respuesta: snakepleskin@gmail.com
Suficiente para una noche de sábado. Poweroff, que nos queda todo el domingo para el tercer nivel del reto.
