During a red team engagement, one of the first things you may want to do after obtaining initial access is establish reliable persistence on the endpoint. Being able to streamline this process can take off the pressure of the operator, leaving them safe in the knowledge that their precious phish won’t be lost in a hurry. In this series of posts I don’t intend to present anything novel or new but will cover off some of my favourite techniques for persisting in Windows environments, presenting examples alongside the advantages and disadvantages of each.
First off, I’ll focus on Microsoft Office (MITRE ATT&CK T1137).
One of my favourite persistence techniques is using Office add-Ins for either Word, Excel or PowerPoint. There are different types of add-Ins supported within Office, however I’m only going to focus on the library based ones as these are typically the most effective in virtual desktop environments and do not require privileges.
Essentially, the Office suite has a number of trusted locations where, when a library is placed, permit user code execution when the Office program is opened, an example is shown below:
The reason this technique is often effective in VDI environments is down to the concept of roaming user profile, which allows a user to maintain the same configurations across different machines in the same domain by storing their profile on a network file share. To achieve this, the user’s %APPDATA% folder is often redirected in the profile meaning that the add-in can be persistent regardless of where the user logs in.
If you want to enumerate the trusted locations from your implant, you can read these values from the registry under the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Security\Trusted Locations\keys, noting you may need to change the version to match up with the version of Office installed (e.g. 16.0 = 2016).
For example, from a Cobalt Strike beacon you can see in this case there’s 8 locations that are marked as trusted:
You can then drill down to further query the individual paths by reading these keys:
In this case the benefit of using beacon’s reg command is its relatively opsec safe since it uses win32 APIs to read the registry rather than calling out to reg.exe or equivalent.
In the interest of brevity, I’ll just focus on creating a library for Word; however I would recommend reading the “Add-in Opportunities For Office Persistence” post by the chaps at MWR.
When placed in a trusted location, Word library add-ins will automatically execute; the add-in is effectively just a DLL and can be executed when loaded by placing your code in the DLL_PROCESS_ATTACH case of the DllMain entry point as shown below where the Run() function will be executed:
From now onwards, whenever Word opens the user code will be executed.
From here you should add your favourite injection and PPID spoofing code to ensure you’re safely escaping the Word process space to maintain your beacon.
In addition to add-ins, there is also the opportunity to persist in an Office desktop environment using template macros. In a similar way to add-ins, these typically live within %APPDATA% so can be useful in VDI environments where roaming profiles are enabled.
The templates are used to customise Office documents and by default a base template exists under the %APPDATA%\Microsoft\Templates\Normal.dotm path for Word and %APPDATA%\Microsoft\Excel\XLSTART\PERSONAL.XLSB for Excel:
Inserting macro code in to these templates can cause it to be executed when a Word document is opened and dependent on the security settings, may execute without any prompting as the directory is by default in the trusted locations:
For example, dropping in a simple MsgBox macro such as the following:
Would then cause the VBA to be executed when the Word document opens:
In the next post, I’ll walk through my second favourite persistence technique; COM hijacking.
This blog post was written by Dominic Chell.
Following this being posted on Twitter, @StanHacked made this interesting point that I felt would be worth updating the post with: