Network attacks often contain a lateral movement stage when adversaries move through the target’s network to find the data or asset that they’re ultimately after.
Read about Philip's other research on manipulating Excel4.0 macros.
In the absence of vulnerable machines or an EternalBlue-like exploit, this phase is carried out by leveraging stolen credentials to achieve execution on a remote machine that’s reachable from an initial foothold in the network.
Unlike the initial intrusion, which is commonly carried out by social engineering or exploiting vulnerabilities, attackers abuse legitimate OS features to conduct lateral movement. On Windows machines, lateral movement is usually carried out using variations on a few methods, particularly Remote Service Creation, Remote Task Scheduling and Remote WMI Process Creation. Closely monitoring these features for strange executions could yield some easy victories against threat actors. Even a meticulously planned campaign using various evasion techniques could be detected simply because the attackers have created a remote service in an environment that monitors this kind of actions closely.
Recently, this arsenal of lateral movement techniques was expanded with some new methods (mostly discovered by Matt Nelson of SpecterOps, and a couple by myself with research help from Oren Ofer) that abuse the DCOM (Distributed Component Object Model) functionality of various Windows applications. This article will review the various methods of DCOM lateral movement (including some that are yet undocumented), assess their use cases and forensic artifacts and offer methods to detect and prevent the use of these techniques.
DCOM is an extension of COM (Component Object Model), which allows applications to instantiate and access the properties and methods of COM objects on a remote computer just like objects on the local machine using the DCERPC-based DCOM protocol. Information about the identity, the implementation and the configuration of every COM (and DCOM) object is stored in the registry, and associated with a few important identifiers:
To make a COM object accessible by DCOM, an AppID must be associated with the CLSID of the class and appropriate permissions need to be given to the AppID. A COM object without an associated AppID cannot be directly accessed from a remote machine.
The Win32_DCOMApplication WMI class provides an easy method to enumerate available DCOM applications by AppID
The instantiation of a remote DCOM object behaves as follows:
Excluding locally instantiated InProcServer classes (which are loaded into the calling process) and objects that are hosted by an existing process, Object creation is handled by the DCOMLaunch service. This service is implemented in the rpcss.dll library and can be identified with the "C:\WINDOWS\system32\svchost.exe -k DcomLaunch" command line. As such, new processes started by COM have the DCOMLaunch service as their parent process. Knowing a process was started via COM, it's easy to determine if it is used locally or remotely. To communicate with a local client, a COM object uses the ALPC (Advanced Local Procedure Call) inter-process communication mechanism. Otherwise, it must communicate with the remote client via the DCOM protocol, which is mostly done on high ports, unless explicitly configured otherwise. A remotely used DCOM object can therefore be identified by a combination of a DCOMLaunch parent and a socket listening on a high port. Office applications specifically are started via COM with the "-Embedding" or the "/automation -Embedding" command line options.
The methods below are grouped by the possible effect their execution may have on a system. Most of these have been published before, and some are variations that, to the best of our knowledge, have never been documented.
First published by Cybereason here.
This uses the recently infamous Direct Data Exchange inter-process communications of Excel to execute an arbitrary command line.
To perform this technique, first create an instance of the "Excel.Application" object, which is the COM object associated with Excel automation. "xxx.xxx.xxx.xxx", in all future examples, stands for a target address:
This is followed by suppression of alerts and execution:
The Excel process runs the chosen command line and tries to establish a DDE channel with said application. It returns an error code upon failing, but the command is still run.
First published by Matt Nelson of SpecterOps here
To perform this technique, first create an instance of the "MMC20.Application" object:
Next, we are able to use the "ExecuteShellCommand" method of the "Document.ActiveView" property to execute our command:
First published by Matt Nelson here
To perform this technique, first create an instance of the ShellWindows object:
We are able to run an arbitrary command using the "ShellExecute" method of the "Document.Application" property:
First published by Matt Nelson
To perform this technique, first create an instance of the ShellBrowserWindow object:
We are again able to run a command via the "ShellExecute" method of the "Document.Application" property:
First discovered by Cybereason
While not a part of the default Office installation and thus not as widespread, Visio provides a DCOM object that could be used for lateral movement.
To perform this technique, first create an instance of the Visio object. This can be done either via the Visio.Application ProgID, or via the Visio.InvisibleApp ProgID:
Visio addons could be implemented as stand-alone processes, and Visio allows to load any executable as a custom addon. This may be leveraged to facilitate execution:
This is a variation on a method discovered by Matt Nelson.
The Outlook object allows the instantiation and interaction with arbitrary COM objects via the "CreateObject" method. This lets an attacker interact with COM objects on a remote machine that are normally unexposed by DCOM.
Command line execution can be achieved by creating the Shell.Application object via Outlook:
Excel XLL Registration
First published by Ryan Hanson here
Excel is extensible by XLL libraries, which are simply DLLs that export specific functions. The Excel.Application object exposes this functionality via the RegisterXLL method.
Word also has an XLL-like add-ins implemented using WLL libraries. These can be added using the "AddIns" property of the Word.Application object:
OutlookScript Execution WIth CreateObject and ScriptControl
First described by Matt Nelson here.
The original technique uses Outlook to access the ScriptControl COM class, which can allow an attacker to run a script supplied in string format:
First discovered by Cybereason
The Visio object provides a direct method to run any line of VBA from a string with the "ExecuteLine" method:
The VBA Engine model in Office is normally inaccesible programmaticaly and needs to be enabled through the "Trust Access to Visual Basic Project" option in the properties menu of every application. This can also be done via the "HKCU\Software\Microsoft\Office\<office version>\<office application name>\Security\accessVBOM" value in the registry for every relevant Office application. Setting these values to 1 remotely (via WMI, for example) allows for the injection and execution of VBA macros into Excel, Word, PowerPoint and Access without supplying a payload carrying document file first.
The macro used for the example will simply run calc.exe:
Executed via Excel:
The Excel version of this was first published by Matt Nelson here.
The above COM objects can also be used to run macro payloads embedded in existing documents in an almost identical manner by using methods to open existing documents and then using the "Run" method to run the macro payload.
DCOM, and especially the Microsoft Office DCOM objects, present a broad attack surface for lateral movement. While these methods leave traces that could be easily detected by a vigilant and informed defender, using them may help an attacker to evade detection and hinder hunting by executing code remotely through mostly unmonitored channels. The vast selection of techniques could help attackers tailor their lateral movement methods to appear as close to noise as possible in a target network. Defenders should apply the prevention advice given, if possible, by closing remote execution channels that are not actively used on the network.
Want to learn how to threat hunt?