No Macro? No Worries. VSTO Being Weaponized by Threat Actors
Office Visual Basic for Applications (VBA) macros have been a core tool in most threat actors’ arsenals for decades.
Their capabilities have enabled clever — and just clever-enough — threat actors to deliver a dizzying array of malware to countless devices around the world. During that time, they have served as what is quite possibly the most commonplace attack vector to infect and compromise Windows PCs. They also acted as a significant component of the first link in a malicious kill-chain that resulted in network compromises, data breaches, and ransomware incidents.
This threat landscape prominence has recently been stifled by Microsoft’s long-awaited decision to block-by-default any VBA macro in Office files bearing the mark-of-the-web (indicating that the file did not originate from the local machine). This significantly reduced this attack surface and forced threat actors to adapt and explore alternative attack vectors.
One of these, which is gaining popularity, is the usage of .LNK (shortcut) files. An example of this can be seen in one of our recent reports.
Another such example is Visual Studio Tools for Office (VSTO). Below we explore some “in-the-wild” examples of how VSTO can become a significant attack vector.
What is VSTO?
A software development toolset, VSTO is available in Microsoft’s Visual Studio IDE. It enables Office Add-In’s (a type of Office application extension) to be developed in .NET and also allows for Office documents to be created that will deliver and execute these Add-In’s.
Additionally, VSTO Add-In’s can be associated with the specific Office application they were developed for (Word, Excel, etc.) and will execute every time that application is booted, offering up an interesting persistence option on top of the code-execution ability.
VSTO Add-In’s can be packaged alongside Office documents (Local VSTO), or, alternatively, fetched from a remote location when a VSTO-Bearing Office document is opened (Remote VSTO). This, however, may require bypass of trust-related security mechanisms.
VSTO as a Threat Vector
In the current threat landscape’s observed state, VSTO is still an uncommon vector (despite being initially discussed quite some time ago). But as is often the case when an esoteric attack vector is involved, it also goes largely undetected by most security vendors, which may lead to it increasing in popularity in the near-term future.
VSTO-bearing Office files contain several indicators which differentiate them from non-VSTO Office files, the primary of which is a contained “custom.xml” XML which contains “_AssemblyLocation” and “_AssemblyName” properties used by the Office application to locate the Add-In and install it.
When VSTO is employed in its local “flavor” the .NET compiled .DLL “Add-In” and its dependencies are stored alongside the Office document created to execute it, commonly in a “container” such as an .ISO file.
In the example detailed below, which targets Portuguese-speaking users, we can see a malicious .ISO file which contains a malicious Word document and a hidden VSTO “Add-In” and its dependencies:
Once the victim opens the malicious Word document, they are encouraged to install the “Add-In” in a very similar fashion to the way victims were encouraged to click the “Enable Content” button and allow a malicious VBA macro to execute.
Once allowed by the user, the malicious “Add-In” will be executed.
Examining the “Add-In” payload reveals it serves to execute an encoded and compressed PowerShell snippet:
An interesting point of note is that the above code’s parent .NET namespace is “schell_test.” This appears to be a reference to a post by Daniel Schell, which predates the appearance of this sample by approximately two weeks.
Decoding and decompressing from the above, the snippet is intended to deliver and execute additional PowerShell code from a Command & Control server:
Unfortunately, we were unable to obtain this additional 2nd-stage code as it had gone offline prior to our investigation of this sample.
VSTO can also be employed in remote fashion, i.e., the Add-In can be stored separately of the Office document created to deliver and execute it. This can make an attack employing VSTO even more challenging to detect or prevent. However, it can also be more complex for an attacker to execute because it requires bypassing various trust-related security mechanisms using a trusted publisher certificate, for example.
In the example below, we can see a reference to a remotely stored VSTO “Add-In” taken from a malicious Word document:
Examining the “Add-In” .DLL payload, which was obtained by cross-referencing threat intelligence data, we can see the following contained code which is intended to download a password protected .ZIP archive, extract it in the user’s %\AppData\Local\ folder, and execute a contained “conhost.exe” file.
Unfortunately, we were unable to obtain the 3rd-stage archive and its contained payload (“conhost.exe”) as it had gone offline prior to our investigation of this sample.
POC of VTSO Attack Scenarios
Partly as an academic exercise, and partly because the final payloads related to the above-described samples were unavailable, we decided to put together a proof of concept (POC) of how VSTO can be used in multiple types of attack scenarios.
In the above video, you can see a demonstration of our proof of concept delivering and executing a Meterpreter payload as well as establishing persistence on the victim’s machine.
The POC code can be found in our public GitHub repository
Please note that we used a simple, highly detectable, Meterpreter payload. This required us to disable Microsoft Windows Defender to film the above video. However, the rest of the POC components went completely undetected.
While VSTO Add-In's are relatively uncommon in the threat landscape due to the capabilities offered both in terms of execution (in theory – an entire fully-featured malware strain can be written and developed in .NET as a VSTO Add-In) and in terms of persistence, we expect more threat actors to adopt and employ them soon. This is particularly true of nation-state and other “high caliber” actors who are more likely to gain the ability to bypass the trust mechanisms present in the Windows environment by means such as a stolen (or otherwise obtained) trusted certificate.
User Execution: Malicious File
User must open a malicious document
Command and Scripting Interpreter: PowerShell
PowerShell code is executed
Subvert Trust Controls: Mark-of-the-Web Bypass
.ISO container file used
Obfuscated Files or Information
Obfuscation used; Password protected file used.
Office Application Startup: Add-ins
VSTO Add-In's may be used for persistence