GoExec v0.3.0 - DCOM Madness

By Bryan McNulty, Offensive Security Operator

TL;DR - GoExec update with new DCOM execution methods using HTA files, Excel, and Visual Studio. Check out the latest release here.

Introduction

Our latest update expands GoExec with four new cross-platform execution methods that abuse DCOM to enable remote code execution during red team engagements. Our goal was to implement effective avenues for lateral movement that use built-in Windows components and other commonly installed software (E.g. Microsoft Office Suite). In GoExec v0.3.0, we introduce DCOM-backed options for HTML Application (HTA) execution (htafile), Excel macro execution (excel macro), Excel XLL add-in loading (excel xll), and Visual Studio DTE command invocation (visualstudio dte). Together, these new execution methods give additional flexibility to the operator depending on the target environment.

1. HTML Application Execution (htafile)

The brand new dcom htafile method leverages the HTML Application DCOM object to execute code through HTA files. This approach was first documented by CODE WHITE GmbH all the way back in mid 2018 with the release of LethalHTA and its accompanying blog post. Their post introduces a DCOM-based lateral movement primitive using the legacy HTML Application class, and details the process of writing the implementation in Windows C++. The development details of this post are not applicable to the cross-platform go-msrpc MSRPC implementation used by GoExec (i.e., we cannot rely on CoCreateInstanceEx), but the underlying method remains relevant.

Although not mentioned in the original finding, the URL moniker passed to IPersistMoniker::Load can use any of the protocol wrappers supported by mshta.exe, including javascript: and vbscript:. These two wrappers introduce the opportunity to execute JavaScript and VBScript without the need for a direct HTA callback. One important limitation however, is that script URLs are limited to roughly 500 characters due to constraints enforced by mshta.exe.

Pros

• Passes tests for all supported Windows versions.
• Does not require that additional software is installed.
• Can execute directly from the client without writing to the Windows filesystem.
• Does not require a callback when using a valid script URL.

Cons

• The underlying class spawns a relatively suspicious process when initialized. This temporary process should show up as C:\Windows\System32\mshta.exe -Embedding.
• The script URL length constraint limits what you can run without a callback.

2. Excel Macro Execution (excel macro)

The dcom excel macro method leverages the Excel Application COM class to execute Excel 4.0 (XLM) macros. This technique requires Microsoft Excel to be installed on the target system and provides powerful execution capabilities through Excel's legacy macro engine. Using the REGISTER and CALL functions, this method enables remote clients to invoke Win32 API procedures directly via XLM. By default, GoExec issues ExecuteExcel4Macro("EXEC(...)");the --macro and --macro-file flags enable execution of custom XLM macros.

Pros

• Underlying process EXCEL.EXE shouldn't be overtly suspicious, especially on workstations.
• Exposes the ability to directly call Win32 procedures by defining custom macros with --macro or --macro-file. This can enable an operator to load shellcode directly into the Excel process like so.
• This method can execute macros directly from the client without writing to the Windows filesystem.

Cons

• Requires Microsoft Excel installation on the remote host.
• The Excel process may be subject to additional monitoring and scrutiny due to a history of attacks.

3. Excel XLL Add-In Loading (excel xll)

The excel xll method invokes Application.RegisterXLL to load an XLL (Excel Add-In) into the Excel process from either a local or UNC path. XLL files are DLLs that may export a number of distinct functions to extend Excel’s functionality. This approach enables controlled code execution within the Excel process. More info on exploitation of RegisterXLL can be found here.

Pros

• Underlying process EXCEL.EXE shouldn't be overtly suspicious, especially on workstations.
• The RegisterXLL function is commonly used to extend Excel, so effectively disguising the payload as a legitimate add-in is feasible.
• RegisterXLL supports both local and UNC paths, so the XLL can be pulled from an SMB or WebDAV server.
• Execution takes place within the Excel process; no fishy child processes are necessary.

Cons

• A Microsoft Excel installation must be present on the remote host.
• XLL payloads must exist somewhere accessible to the target, so either a SMB/WebDAV callback or file transfer is necessary.

4. Visual Studio DTE Execution (visualstudio dte)

The Visual Studio DTE (Development Tools Environment) method leverages the VisualStudio.DTE object on devices with Microsoft Visual Studio installed, as detailed in a blog post by Juan Manuel Fernandez in late 2023. This technique operates through Visual Studio's own command system, with command execution enabled via the Tools.Shell command.

Pros

• Execution can be achieved without writing to the remote filesystem.
• Implementation includes the ability to specify custom Visual Studio commands with --vs-command and --vs-args.

Cons

• Requires a Visual Studio installation (2022 or 2019 with --vs-2019) on the remote host.
• Limited to standard shell execution unless a custom method is performed with --vs-command and --vs-args.

Conclusion and What's Next

This post serves as an insight into our thought process when integrating new features into GoExec. For each new technique we assess reliability, target prerequisites, and potential uses in red team operations. The goal is to illuminate why certain DCOM abuses remain viable in modern environments.

Looking ahead, FalconOps is publishing new research focused on uncovering obscure DCOM interfaces that enable code execution beyond the commonly cited methods.

FalconOps

Want the operator who wrote this tool to hack your company? Get a quote today without a quick call using the button at the top.