Introduction

Visual Studio Tools for Office (VSTO) “is a set of development tools available in the form of a Visual Studio add-in (project templates) and a runtime that allows Microsoft Office 2003 and later versions of Office applications to host the .NET Framework Common Language Runtime (CLR) to expose their functionality via .NET” (Wikipedia).  For unprivileged users, VSTO “add-in” applications can be installed in the context of a user profile without admin intervention and will run each time the respective targeted Office application (e.g. Word) is invoked.  For defenders, this is (yet) another vector to monitor for possible abuse within the IT environment.

What can an attacker (potentially) do with VSTO?

The use cases for VSTO are pretty interesting depending on environmental factors.  Here are some possibilities:

• Application Whitelist Bypass –  After clicking through the warning banner and installing the VSTO application as a normal user, the add-in payload launches after opening the Office application.  AppLocker Policy (configured with default rules) does not prevent this code execution.  Refer to the “VSTO Walkthrough” section for more information about the execution results and scenario.
• Social Engineering – With a properly signed certificate, the VSTO application can be published and deployed with ClickOnce via a Microsoft Web Browser delivery method (or by means of some other trickery).  For more information about using ClickOnce as a potential attack vector, check out ClickOnce (Twice or Thrice): A Technique for Social Engineering and (Un)trusted Command Execution.
• Low-Privileged Persistence – Each time the Office application is opened, the add-in payload will launch.
• (Round-About) Lateral Movement – In retrospect, add-ins installed under the context of a roaming profile will execute on other workstations if the user migrates between workstations.  This potentially increases the opportunity for a persisted attacker to evaluate the security posture of a variety of machines and perform privilege escalation/post-exploitation attacks.

Please, Tell Me More About This “VSTO” Application

VSTO (.vsto) is actually a manifest file that is bundled with a collection of files for VSTO application deployment and installation.  Upon compilation in Visual Studio (Visual C#), the VSTO release bundle is created with the following files:

• <appname>.vsto – VSTO Manifest
• <appname>.dll – VSTO Assembly
• <appname.dll>.manifest – VSTO Assembly Manfest
• <appname>.pdb – VSTO Debugging Information
• Microsoft.Office.Tools.Common.vX.X.Utilities.dll –  Visual Studies Helper Assembly

With other options selected within Visual Studio, it is possible to bundle other (pre)requisite files for application compatibility.  When “optionally” deployed with ClickOnce, the VSTO bundle is ‘published’ within a ClickOnce Directory structure that includes a ClickOnce VSTO deployment manifest file.

VSTO Walkthrough

This POC walkthrough will consist of VSTO application payload creation, compilation, installation, and execution.  Let’s begin…

First, we create a project in Visual Studio.  For VSTO, we must  (and we do) have the VSTO prereqs installed.  To create a project, we select Visual C#, Office/SharePoint, and the VSTO add-in for an Office application.  For this exercise, we choose Word and call the project vstoevil…

Visual Studio sets up our baseline template.  We edit the ThisAddIn_Startup function with our payload.  In this case, we will invoke notepad.exe…

Open the project properties menu.  Under Application, verify or edit the target framework.  Changing the target framework will likely result in the refreshing the Visual Studio project, but it should take us back to this screen afterward.  For this exercise, we’ll stick with the current framework…

Select properties/options as necessary.  Under Signing, this is where an important decision has to be made with regard to signing the ClickOnce manifest.  A legitimate cert has its own merits (but other requirements) for installation (such as in a social engineering situation).  A self-signed cert is easy to create but will likely prevent installation/execution of the payload (such as in a social engineering situation).  In our example, we are going to self-sign without a password.  However, we will not be installing with a ClickOnce deployment package in this walkthrough.  In our lab, ClickOnce will likely fail due to policy and the ClickOnce deployment wizard certificate check.  Instead, we are going to move the compiled bundle (as outlined above) to the lab machine and directly execute the VSTO manifest installer…

Under Publish, this is where you can set options for managing the deployment package such as web publishing, version increments, update checks, prerequisite software, file dependencies, etc.  For now, we will remove pre-reqs and set a publishing path but keep everything else at a default level…

Let’s go ahead and “Publish” the project.  This will compile the code as well as prepare the ClickOnce Application.  Since our attention is only on the compiled code, we verify the contents within the “Release” directory…

We move our VSTO bundle to the target machine that is configured with Default AppLocker Rules.  Our logged-in user does not possess any administrator rights or privileges.  For validation of rules, let’s attempt to load vstoevil.dll directly.  You may recall control.exe from another blog entry…

As expected, our DLL assembly was prevented from running due to AppLocker rules.  Let’s invoke the vsto installer (vstoinstaller.exe) by executing vstoevil.vsto.  We are prompted with a sanity check…

(Un)Fortunately, our unprivileged user account can perform a “no-admin” installation of this package.  After installation and verification, we launch Word to see our new add-in and payload results…

Success! Notepad.exe is executed when the VSTO add-in program is loaded in Word.

Blue-DFIR-Defensive Considerations

VSTO application deployment is not very stealthy.  Monitor for VSTO file execution in logging facilities, untrusted/previously unseen certificates, and registry key/value creation.  Additionally, check for “installed programs” as an entry will likely be created under the user’s ‘Unistall’ Registry Key.  Consider adding VSTO files to Application Whitelisting policies.  Refer to the MSDN document Registry Entries for VSTO Add-ins for more information.

Other Research

• @gN3mes1s tweeted about VSTO on in early December as well as offered a few helpful tidbits.  VSTO does indeed offer a nice persistence technique with the right registry key.  For defensive considerations, keep an eye out for interesting child processes of parent Office applications.
• 2/4/2018 – While researching further, I came across an excellent write-up by MWR Labs that covers Microsoft Office Add-Ins as a persistence technique.  VSTO add-ins are covered as well as xLL, COM, etc.  The “Defending Against Malicious Add-Ins” is well worth the read.

Conclusion

As I wrap up this post, I stand behind the disclaimer that I am not a VSTO expert.  I have not seen many security-related articles about this topic, but it does seem like an interesting area for further research.   Also, feel free to contact me or leave a message if you have any other questions/comments. I will try to update this page regularly with related research links as they become visible. Thank you for reading and happy hunting!