Puesto de usuario – Nivel básico
1. ¿Qué dirección IP tiene el puesto de usuario?
El registro lo sabe TODO. En este caso, el hive SYSTEM:
Un poco de RegistryExplorer y ya tenemos la respuesta:
* Respuesta: 74.118.138.195
2. ¿Cuál es el SID de la cuenta de Administrador?
El SID (Security Identifier) es un valor único e inmutable que se le da a cada cuenta de usuario en el momento de su creación.
Podemos ser especialmente sucios y tirar de los perfiles de usuario (en los que se guardan datos de cada usuario, y que están referenciados por su SID). Buscamos con RegistryExplorer en:
y de ahí sacamos el valor con rapidez:
* Respuesta: S-1-5-21-1769714682-2803786108-491265710-500
3. ¿Cuál es el offset de la timezone en la que está el equipo? [Ejemplo: -1]
Esta ya la habíamos medio respondido en el primer nivel. Los datos de timezone están (cómo no) en el registro de Windows:
En esta ocasión ya me ha hecho efecto el primer café de la mañana, y he leído la pregunta correctamente. Lo que piden es el desfase en horas de la zona con respecto a UTC. Según lo que indica el valor Bias estamos en 480 min, lo que se traduce en -8 (confirmado al buscar el valor en texto de Pacific Standard Time). Sin embargo, a la hora de crear el reto estaban en horario de verano, por lo que se quita 1h, quedando el offset en un precioso -7.
Que no funciona. Y tendría que hacerlo. Probamos el -8 sin éxito… y decidimos que es domingo, así que vamos a por la fuerza bruta. Los supertacañones aceptan como respuesta válida -4, pero si alguien sabe explicarme porqué, se ganará una birra :D
* Respuesta: -4
4. ¿Qué nombre tiene el directorio borrado de la shadow copy en la papelera?
Toca huronear un poco en la papelera. Si navegamos por la estructura de directorios con FTK comprobamos que hay varios ficheros de interés, pero en este caso FTK Imager no me deja visualizar su contenido (raro raro). Como siempre es bueno poder recurrir a otras herramientas, en este caso vamos a usar wxHexEditor, que nos deja ver el contenido del fichero $IFATB0K y con él nuestra respuesta.
* Respuesta: $IFATB0K
5. ¿A qué directorio copió el atacante los ficheros desde el VSS?
Vamos primero a coger los apuntes de primero de lengua para entender la pregunta. Al parecer el atacante copió los ficheros del VSS a algún directorio, cuyo nombre es lo que nos piden averiguar.
Dado que el VSS está en la papelera, es posible que el otro directorio también haya sido borrado. Rebuscando entre el resto de directorios encontramos que hay dos ficheros: SAM y SYSTEM, y si rebuscamos un poco más encontramos nuestro resultado:
* Respuesta: temp
6. ¿Cuál es el nombre del fichero que exfiltró el atacante?
Seguimos en el entorno de la papelera. El atacante se ha quedado con el SAM y el SYSTEM del equipo (como en el nivel anterior), y justo al lado observamos un Desktop.7z. En muchos casos los atacantes agrupan y comprimen los resultados para facilitar su exfiltración (lo que se denomina staging). Si lo descargamos y lo abrimos comprobamos que tiene esas hives del registro, lo que confirma nuestra teoría.
* Respuesta: Desktop.7z
7. ¿Cuál es la IP del sitio de Magnetic Forensics accedido por el atacante?
Nos toca revisar de nuevo el historial de navegación. En este caso BrowsingHistoryView funciona correctamente y nos da el historial de todos los navegadores. Si buscamos por la cadena “magnetic” no encontramos nada más que accesos a Outlook y Google Docs. Sin embargo, aparece una dirección IP repetidas veces: 74.118.139.108
Si nos damos cuenta, esta IP es muy parecida a la del desktop (74.118.138.195), así que posiblemente sea la que busquemos. Y en este caso, acertamos :D
* Respuesta: 74.118.139.108
8. ¿Cuál es la contraseña del administrador?
Bueno, aquí podemos seguir un poco el hilo del atacante. Si quieres sacar las contraseñas en local tienes que obtener los hashes y luego crackearlos. Los hashes los obtienes (obviamente) del registro, siendo exactos de las hive SAM y SYSTEM (justo las que se ha llevado puestas el atacante, qué coincidencia).
Teniendo los hive solo falta tirar de Mimikatz para que haga nuestro trabajo sucio (no sin antes bajar el AV de nuestro Windows para que no se asuste el pobre)
Nuestro hash NTLM es: 4d55663e41abd66cf17584c9c9f7c86c
Tiramos de Hashcat y nuestra maquinita de password cracking y sacamos el resultado en menos de 1 hora.
* Respuesta: supersecretpassword
Puesto de usuario – Nivel avanzado
9. ¿Cómo entró el atacante en el Sistema?
Pregunta libre, así como aperitivo (se está haciendo un costillar barbacoa a fuego lento, así que todavía tengo dos horas para el reto… aunque tengo HAMBRE). Vamos a empezar a analizar logs y ver qué sacamos:
Aquí tenemos un Powershell malicioso como la copa de un pino. Aunque no tengamos un detalle exacto de cómo ha llegado hasta ahí, nos da un marco temporal del incidente.
Analicemos la MFT en ese día a ver qué encontramos (recordad que para convertir a UTC hay que restar dos horas, por lo que estaremos buscando nuestra actividad maliciosa alrededor de las 18:40h). Y vaya si encontramos cosas ordenando los ficheros por su fecha de acceso (solo ponemos los bocados jugosos):
Ejecución de Powershell:
Descarga de un .hta de Internet y ejecución
Ejecución de ipconfig (comando clásico de reconocimiento)
Conexión por Team Viewer
Este último es que nos da premio. Si os fijáis con cuidado parece que el fichero ha sido creado y accedido al mismo tiempo, lo que nos indica que es la primera vez que ha sido usado. Si recuperamos el fichero de disco y lo examinamos tenemos nuestro resultado:
Todavía no sabemos cómo ha conseguido las credenciales, pero el acceso ha sido mediante un honesto y trabajador TeamViewer
* Respuesta: TeamViewer
10. ¿Cuándo inició sesión el atacante por primera vez en el equipo? [formato UTC TIme Date Format Month/Day/Year 24 Hour Time 1/1/2018 22:00:00]
Qué bien sientan los combos de respuestas, otro 2×1 :D . Salvando de nuevo la maldita costumbre americana de los bailes de días y meses, tenemos la respuesta en nada:
* Respuesta: 08/07/2018 18:34:43
11. ¿Qué cuenta empleó el atacante para iniciar sesión a través de rdp?
Esta parece bastante sencilla porque tan solo tenemos que revisar los logs de Terminal Server. Sabiendo que el ataque se produce sobre las 18.40h (20.40h en los logs), buscamos conexiones:
… pero inexplicablemente no nos la aceptan como correcta. Seguimos buscando:
El segundo intento es Administrator, que es aceptado como correcto (aunque no queda del todo claro el motivo).
* Respuesta: Administrator
12. ¿Cuándo cambió la constraseña por última vez la cuenta que acabas de identificar? [formato UTC Time Format Year-Month-Day 24 Hour Time 2018-01-01 14:01:01]
El último cambio de contraseña se queda guardado en la SAM. Regripper + SAM y salimos corriendo con la respuesta (que ya teníamos de respuestas anteriores):
* Respuesta: 2018-08-07 19:31:56
13. ¿Qué le dio al atacante acceso al resto de cuentas de Max Powers?
Aquí tenemos una respuesta rápida. Como ahora tenemos un puesto de Escritorio deberíamos de tener una carpeta en C:\Windows\Prefetch en la que se quedan guardadas las últimas ejecuciones de programas. Un poco de WinPrefecthView nos debería de dar la respuesta:
KeePass (un conocido gestor de contraseñas) está instalado en el equipo. Y si buscamos por ficheros con la extensión .kdbx comprobamos que el usuario mpowers tiene un fichero de KeePass en “Mis Documentos”. Si lo buscamos en la MFT comprobamos además que el fichero había sido accedido poco antes de la intrusión:
por lo que es posible que, o bien el usuario empleara la misma contraseña para su KeePass … o que estuviera abierto cuando el atacante iniciara sesión por TeamViewer.
* Respuesta: KeePass
14. ¿Cuál es el nombre del fichero que almacena la información que has identificado en la pregunta anterior?
Pin pan pum. Como a Hannibal Smith, “me encanta que los planes salgan bien” … y que las respuestas vengan de dos en dos.
* Respuesta: safeplace.kdbx
15. ¿Cuál es la contraseña del fichero que has identificado que permitió al atacante acceder al resto de sistemas?
Esto suena a más trabajo para nuestro Hashcat. Tan solo es necesario extraer el password cifrado del fichero de Keepass, algo que podemos hacer con el script keepass2john. Una vez convertido podemos usar John the Ripper o Hashcat al gusto
Ya que hemos usado antes hashcat, ahora vamos a usar John the Ripper.Sacamos a pasear el diccionario de varios millones de palabras cuidadosamente construido… y el password resulta ser 123456:
Referencias:
* Respuesta: 123456
16. ¿Qué contraseña tiene el usuario max powers en el servidor de ficheros? (la respuesta es sensible a mayúsculas)
Tenemos el fichero de KeePass, y tenemos la contraseña. Tan solo nos hace falta el software, del que podemos descargar una versión portable aquí:
https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.40/KeePass-2.40.zip/download
* Respuesta: DhhZrwRyEOQwbiJl97a4
17. ¿Cuál es la dirección IP del equipo de adquisición de la imagen forense?
Ya sabemos por otras preguntas que el Blue Team está usando F-Response, así que nos cuesta poco localizarlo en el Escritorio del usuario mpowers. Para saber cuándo llegó allí tan solo tenemos que preguntarle a la MFT:
La MFT nos indica que el fichero se creó el 7 de Agosto a las 23:54, y que fue accedido la última vez el día siguiente a las 16:48, por lo que ya tenemos un marco temporal. Vamos a ver qué nos dicen los logs al respecto. Nos dedicamos a revisar el log del cortafuegos de Windows buscando por reglas que permitan el acceso interno al puerto 5682 (el que la documentación de F-Response indica que se usa por defecto) sin éxito.
Sí que encontramos una buena cantidad de reglas que dejan el acceso a este programa:
Ruta de acceso de la aplicación: C:\users\mpowers\desktop\sub-win-x64_104.148.109.107_5682_3262.exe
Que curiosamente en su nombre tiene la cadena “5682”, y que está en la misma carpeta que el fresponse.msi. Si lo extraemos de la imagen ya podemos ver la “F” característica de F-Response. Para asegurarnos calculamos su hash, y preguntamos a VirusTotal
En efecto, el fichero pertenece a F-Response. Si lo ejecutamos en una VM Windows parece ser el cliente de adquisición, en el que aparece la IP como servidor de licencias.
Referencias:
* Respuesta: 104.148.109.107
Puesto de usuario – Nivel experto
18. ¿Cuál es la dirección IP y puerto usados para alojar el código malicioso empleado en el primer ataque?
En la pregunta 49 hemos visto en la MFT que se han descargado un .hta, y el sufijo “:Zone.Identifier” implica que ha sido descargada desde Internet.
Toca analizar la navegación del usuario mpowers con BrowsingHistoryView… y encontramos algo muy interesante justo antes de que empiece la actividad maliciosa:
Al parecer el usuario mpowers ha accedido a su correo en Office365 (email – mpowers@magnetic4nsics.com), y justo después se ha cargado una hoja de Google Docs. Si miramos la URL en detalle encontramos algo muy interesante:
Tiene toda la pinta de un phishing en toda la regla. Y el último acceso a “formResponse” parece indicar que el formulario ha sido completado, lo que le da al atacante las credenciales de acceso al sistema. Si accedemos a esa hoja de Google (siempre desde Tor y con muuuuucho cuidado) nos encontramos con que Google ya la ha tirado abajo por ser maliciosa:
Todo esto es muy ilustrativo para ver qué ha pasado en el ataque, pero no nos contesta a la pregunta. Sabemos el nombre del fichero con el código malicioso (out.hta), sabemos que ha sido descargado desde Internet y sabemos el marco temporal. Si no está en los resultados del BrowsingHistoryView hay varias posibilidades:
- El atacante se ha descargado el código usando “algo” que no es un navegador.
- El atacante ha limpiado sus huellas.
- La herramienta BrowsingHistoryView no está funcionando tan bien como debería.
Dado que BrowsingHistoryView ya nos ha dado problemas en este reto (creo que puede ser debido a Windows 10) vamos a acceder a pelo al historial de Chrome como ya hemos hecho anteriormente. Un poco de nuestra herramienta para abrir BD SQLite y ya tenemos nuestra respuesta localizada:
¡Ouch! No parece gustarle la respuesta. Dándole unas cuantas vueltas al coco, a lo mejor se refieren a lo que pueda estar metido dentro del out.hta encontrado en el punto anterior. Si accedemos al fichero en cuestión con FTK Imager comprobamos que es un clásico dropper de Powershell con el código en base64:
Que podemos decodificar con alegría para comprobar el código fuente del Powershell a ejecutar:
Puesto en bonito y formateado ligeramente con Sublime Text tenemos la respuesta:
* Respuesta: 142.93.50.86:80
19. ¿Cuál es el nombre del fichero ejecutado por el atacante desde la IP identificada anteriormente?
¡Otro combo 2×1! La currada de la pregunta anterior nos deja la respuesta hecha.
* Respuesta: out.hta
20. ¿Qué programa es realmente?
Recordar, no se dan de comer a los Gremlin después de medianoche, y no se suben muestras de bichos a VirusTotal en mitad de un incidente. Pero lo que sí que podemos hacer perfectamente es calcular el hash con HashMyFiles:
Y subir el hash a VirusTotal, lo que nos da una coincidencia:
En efecto, es malicioso pero sin tener un nombre concreto. Ya que tenemos el script entero, vamos a buscar alguna cadena característica, por ejemplo la siguiente:
El primer resultado de Google es suficiente:
El culpable es nuestro querido y odiado Empire, post-explotación para Windows a la carta 24×7 con todos los extras que un atacante puede desear para liarla parda en nuestro sistema.
* Respuesta: empire
Conclusiones
Al final han sido unas 40h+ invertidas en conseguir terminal el reto, con preguntas fáciles y complicadas, divertidas y un poco coñazo. Vamos, como casi todos los retos
Quizás el problema que le podría encontrar es la didáctica final. En muchos CTF de seguridad se trabaja en responder preguntas de diversas categorías, que casi siempre tienen poca o nula relación unas con otras.
Sin embargo, un reto de DFIR tiene una oportunidad única: el hacer que responder las preguntas vaya desgranando poco a poco el incidente. De esta forma se consiguen dos objetivos: por un lado, el aprender a resolver cuestiones individuales y por el otro (y casi más importante) el aprender cómo se resuelve un incidente a través de las preguntas planteadas. En este caso el hilo conductor no está mal, pero una orientación de un tipo más “contar una historia” habría sido mucho más didáctica.
Pros
- He terminado el reto de la DEFCON (eso tiene que dar por lo menos +500 PX, o al menos un poco de satisfacción personal
- He refrescado cosas que tenía medio muertas de la estructura interna de NTFS
- He aprendido a manejar herramientas para gestionar shadow copies
Cons
- El reto era más largo que un día sin pan. Un reto de 63 preguntas es solo para los que hacen ultramaratones.
- Algunas preguntas se han quedado con una respuesta un tanto vaga (pero es algo endémico de muchos retos, dependiente en muchas ocasiones de la plataforma empleada)
En general un buen sabor de boca con el reto. Y a nivel meta, más ideas y experiencias para aprender a cómo hacer mejores retos …
Muchas gracias, muy buena relación/apuntes para poder aprender.
Unas dudas básicas:
-Herramientas como privazer o similares, para poder tocar ramas de registro fuera de HKCU, o el USNJournal o la MFT, requieres de privilegios de administrador, en un análisis forense, ¿qué tipo de herramientas o técnicas se pueden usar para detectar que un usuario sin privilegios ha llegado a conseguir credenciales de administrador?.
-Mucha parte del reto se consigue gracias a que los sistemas tienen habilitadas las Shadow Copies; en entornos donde no estén activas, o si el atacante es listo las borra antes, ¿hay alguna manera de llegar a completar la información sin ello o simplemente se puede llegar a indicar que se han borrado y por tanto no se pueden sacar más evidencias?
Gracias de nuevo!
Muy buenas tardes,
Como bien has indicado en el comentario, toda herramienta de borrado de huellas requiere de privilegios de administrador para poder acceder a todo el sistema. Existen muchos métodos para escalar privilegios (este es un buen tutorial al respecto: http://www.fuzzysecurity.com/tutorials/16.html), y no hay una técnica “única” para detectar cuándo se ha producido.
En algunos casos puedes tener una cierta sospecha (se ha ejecutado un comando concreto, un proceso de sistema ha tenido un fallo grave) pero en realidad se van recogiendo indicios a lo largo de la investigación. El proceso suele ser del estilo de: “el atacante ha hecho A, B y C … y de repente !zas! ha hecho D como administrador”. Pocas veces tienes una pistola humeante, suele ser más bien una conclusión lógica de la actividad que se observa en el sistema.
Y con las shadow copies… pues si no están, no están. Tal y como se crean, si se borran hasta donde yo sé su recuperación es altamente improbable.
[AutoUpdate]: He buscado un poco en Google y existe una herramienta para hacer carving de shadow copies publicada hace dos meses: https://github.com/mnrkbys/vss_carver , así que se podría intentar recuperarlas (muchas gracias por hacerme encontrar esta herramienta, va a la saca)
Aun así, las shadow copies son una fuente de información más a la hora de realizar un análisis forense. Siempre quedan múltiples lugares donde buscar información que nos pueda ayudar a resolver el caso … y también hay que asumir que, en muchos casos, nunca vamos a poder completar el puzzle porque por así decirlo “nos faltarán piezas” O:)
Un saludo,
Antonio
Muchas gracias de nuevo Antonio por compartir tu conocimiento :-)
Un saludo