No Macro? No Worries. VSTO Being Weaponized by Threat Actors

Introduction

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.

Local VSTO

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.

Remote VSTO

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.

Conclusion

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.

IOCs

5530F5D20016E3F0E6BBC7FAD83EEC56F118179D4C5D89FC26863C37482F8930
E74DD27FF0BA050BBC006FD579B8022E07B570804588F0E861CC4B1321A3EC48
0526F63486DE882CCF33374DCA4B093219A8FD93014BABE794715F04FF49B151
B3282DC58AD961911D94B712CEA11F649B0BA785D7FF74D7ED9946E1260DD521
40C9D3D58CE5DB0C6D18184E5813C980CD7B72EFC7505C53CD13E60860EF8157
78D6A2C0B52E9E5AF8007BC824EFD5846585A3056B3A0E6EFDFA7E60EED48C8C
hxxps://34.241.171.114/
hxxp://classicfonts.live/

MITRE Mapping