D(COM) V(ulnerability) S(canner) AKA Devious swiss army knife - Lateral movement using DCOM Objects

Did you ever wonder how you can move laterally through internal networks? or interact with remote machines without alerting EDRs?
Let's assume that we have a valid credentials, or an active session with access to a remote machine, but we are without an option for executing a process remotely in a known, expected or a highly-monitored method (i.e. WMI, Task Scheduler, WinRM, PowerShell Remoting).

For these scenarios, the DVS framework comes to the rescue.

The DVS framework is a swiss army knife which allows you to enumerate vulnerable functions of remote DCOM objects, launch them and even launch attacks using them.

The framework is being developed with a "Red Team" mindset and uses stealth methods to compromise remote machines.

The DVS framework contains various ways to bypass remote hardening against DCOM by re-enableing DCOM access remotely and automatically grant the required permissions to the attacking user.

The framework can also revert changes on the remote machine to their original state, prior to the attack - hiding these changes from defenders.

Our main insight is that the tool can also execute commands using non-vulnerable DCOM objects through an aqsome technique (Read below about Invoke-RegisterRemoteSchema)

Compatible with PowerShell 2.0 and up

Youtube Video PoC: DVS

Disclaimer

This tool is for testing and educational purposes only. Any other usage for this code is not allowed. Use at your own risk.
The author bears NO responsibility for misuse of this tool.
By using this you accept the fact that any damage caused by the use of this tool is your responsibility.

Registry access - how the DVS framework utilizes that protocol

• Remote-Registry access(MS-RRP)

  1. Probe port 445 port in order to interact with the remote registry
  2. Check if the remote-registry is enabled
  3. Interact with the remote registry
  4. If AutoGrant mode is flagged, check write permissions. otherwise, check read permissions

• Standard Registry Provider (If remote-registry denied)

  1. Probe port 135 in order to interact with the "Standard Registry Provider" using WMI
  2. Check if the StdRegProv is accessible
  3. Interact with the Standard Registry Provider
  4. If AutoGrant mode is flagged, check for write permissions, otherwise, check for read permissions

Why is this tool so stealthy?

The DVS tool first checks if principal-identity has access to the remote machine via the following steps:

• Basic actions

  1. Authentication operations (if SkipRegAuth is not flagged)
     1. If credentials are provided, it creates a "net-only" session. otherwise, it will use the current-logged on session.
     2. Probe registry access.
  2. Check if DCOM feature is enabled
  3. Allow DCOM Access (if AutoGrant flagged), otherwise fail
  4. Check if the logged-on user/provided user and the groups the user is a member of (Via adsi/WindowsIdentity feature), are granted to interact with the DCOM (via remote registry queries)
  5. Grant permissions (if AutoGrant flagged), otherwise, fail
  6. Resolve domain name from remote machine using NetBIOS over TCP(Using NetAPI32, or UDP Packet), if it fails it will try using the registry (HKLM or HKCU Hives)

• Invoke-DCOMObjectScan

  1. Interact with DCOM objects
  2. Enumerate the DCOM object and find vulnerable functions
  3. Validate exploitation possibility
  4. Generate execution payloads
  5. Fetch personal information about the vulnerable DCOM object

• Get-ExecutionCommand

  1. Generate execution payloads

• Invoke-ExecutionCommand

  1. Try to interact with DCOM objects
  2. Execute the commands

• Invoke-RegisterRemoteSchema

  1. Try to interact with one of the following DCOM Objects:
     • InternetExplorer.Application - InternetExplorer COM Object
     • {D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E} - Another COMObjects belongs to Internet Explorer
     • {C08AFD90-F2A1-11D1-8455-00A0C91F3880} - ShellBrowserWindow
     • {9BA05972-F6A8-11CF-A442-00A0C90A8F39} - ShellWindows
  2. Register remote schema (e.g. http://)
  3. Configure the schema to execute commands from the schema content
  4. Execute the command

Tool components

• Security rights analyzer - Analyzing principal-identity rights to access the remote DCOM object
• Remote grant access - Grants logged-on user permissions remotely (In case they were not already granted)
• DCOM Scanner - Scan and analyze remote/local DCOM objects for vulnerable functions that are provided (Patterns and function names must be specified) When the tool detects a vulnerable function, it will check what arguments the function includes and if the function has the ability to execute commands
• DCOM command generator - Generates a PowerShell payload in order to execute on the remote machine
• Report - Generates a CSV report with all the information about the vulnerable DCOM object
• Command Execution - Execute commands through DCOM objects

Author

• Nimrod Levy

License

• GPL v3

Tested Scenarios

• Out-of domain to domain
• From inside the domain to another domain-joined machine
• From domain to out-of-domain
• From current-session to another domain-joined machine

Tested Operating Systems

• Windows 7 SP1
• Windows 8.1
• Windows 10
• Windows Server 2019

Credits

• Thanks to Rafel Ivgi for mentoring, and helping with the architecture mindset of the tool.
• Thanks to Yossi Sasi for helping me to optimize the script.
• Thanks to Gleb Glazkov for writing the mitigation and preventions section

Installation:

git clone https://github.com/ScorpionesLabs/DVS
powershell -ep bypass
PS> Import-Module .\DVS.psm1
PS> Get-Help Invoke-DCOMObjectScan -Detailed  # Get details of the Invoke-DCOMObjectScan command
PS> Get-Help Get-ExecutionCommand -Detailed # Get details of the Get-ExecutionCommand command
PS> Get-Help Invoke-ExecutionCommand -Detailed # Get details of the Invoke-ExecutionCommand command
PS> Get-Help Invoke-RegisterRemoteSchema -Detailed # Get details of the Invoke-RegisterRemoteSchema command

Invoke-DCOMObjectScan

Invoke-DCOMObjectScan function allows you to scan DCOM objects and find vulnerable functions via a list of patterns or exact function names that you included in a file.

• Examples:

  1. Enumerates and Scan MMC20.Application (ProgID) object from the attacker machine to the DC01 host without querying the registry.

        Invoke-DCOMObjectScan -Type Single -ObjectName "MMC20.Application" -HostList DC01 -SkipRegAuth -Username "lab\administrator" -Password "Aa123456!" -Verbose
     

  Note: The tool will not analyze ACL permissions, and when the tool will success, it will resolve all the information about the object, except the details mentioned on the registry(Like object name, executable file, etc.)

  2. Check whether the MMC20.Application (ProgID) object is accessible from the attacker machine to the DC01 host without first querying and verifying the access list of the DCOM object.

        PS> Invoke-DCOMObjectScan -Type Single -ObjectName "MMC20.Application" -HostList DC01 -SkipPermissionChecks -CheckAccessOnly -Verbose
     

  3. Validates whether the MMC20.Application (ProgID) is applicable through 10.211.55.4/24 range. If exists, he tool will try to enumerate the information about it. (using the current logged-on user session).

        PS> Invoke-DCOMObjectScan -Type Single -ObjectName "MMC20.Application" -Hostlist "10.211.55.4/24" -CheckAccessOnly -Verbose