Party like it’s 1999: Comeback of VBA Malware Downloaders [Part 2]

Party like it’s 1999: Comeback of VBA Malware Downloaders [Part 2]

Authored by:  Alexander Sevtsov, and Arunpreet Singh

Find more details on this series in Part 1 and Part 3.

The use of malicious macro code in Microsoft Office documents is seeing a big comeback in recent weeks. As we already discussed in the first part of this blog-post series, this malicious code gives attackers a very simple but powerful means to attack users. At the same time, the simplicity of the attack comes at the price that it is somewhat easy to detect (when compared to binary malware) if the attacker does not pay special attention to hiding his/her code.

Unfortunately, attackers do hide their code, and, unlike the basic idea of VBA malware, the evasion attempts are quite sophisticated. While the first part of the series focused mostly on the static component of these attacks, we will dive into how attackers try to circumvent dynamic analysis – the core piece of most modern security solutions – in this second part of the series. As before, we explain the tricks in detail and show examples of real-world malware in an attempt to make these tricks widely known and allow the community to build adequate detection to protect users.

Behold the Autostart: Execution on Document_Close

There are several event procedures used for running VBA code: for example, the macro execution can be triggered when the document is opened (once macros have been enabled). This is the most commonly used technique to execute the malicious macro nowadays. However, we have recently faced examples that run the VBA code when the document is being closed (using the Document_Close or AutoClose event), which can be considered as a very effective evasion technique against dynamic analysis environments where the file is opened but never closed before the analysis timeout is reached.

Let’s look at an example that uses the following VBA code to trigger the attack payload:

Public Function e0cfd0c8cff0eecbd0c8(ByVal lZukbpzi As String) As String
For TQmHIScQAQjD = 1 To Len(lZukbpzi) Step 2
Dim iYOdnVVIvQs As Integer
[…]
Next iYOdnVVIvQs
[…]
End Function

Sub GHUVhjsdfVHJ()
GVhkjbjv = e0cfd0c8cff0eecbd0c8(“[…]8696F49482E6578653B”)
cff0eefbe2ebe0 = Shell(GVhkjbjv, 0)
End Sub

Sub HBjkbjBJKBL()
GHUVhjsdfVHJ
End Sub

Public Sub AutoClose()
HBjkbjBJKBL
End Sub

Once the document is closed, the code exposes the following behavior:

image00-2.png

Handling this type of evasion is somewhat tricky, because the analysis system needs to find the correct time to invoke this event handler (e.g., by closing Microsoft Office). Closing the program too early can interrupt an ongoing exploitation attempt – memory corruption attacks can take some time – or a macro may be in the middle of execution. Thus, terminating the process without giving the attack sufficient time to execute its payload causes the analysis system to miss the malicious behavior.

The Lastline analysis engine has the ability to monitor CPU activity and other important system metrics, such as network activity, during the analysis. This allows us to detect when system load has come to a normal level, which indicates that any document loading code has completed and that no other jobs, such as macro code, are executing, and provides a good time to trigger additional behavior by closing the document.

Identifying Targets: Checking Most Recently Used (MRU) Documents

In another document file, we have seen the following VBA-code (deobfuscated for better readability), which aims to download and execute a payload, checking beforehand if the sample runs within a sandbox environment. This is achieved by checking the number of recently accessed files (MRU) and geo-location information:

Private Sub Document_Open()
On Error GoTo exception
CheckRecentFilesCount
CheckAnalysisEnvironment
DownloadAndExecute
Exit Sub
exception:
[…]
End Sub

The MRU files in Microsoft Office are those documents that have been recently opened by the user. This information is stored under the following registry key:

HKEY_CURRENT_USERSoftwareMicrosoftOffice%VERSION%%APPLICATION%File MRU

which is 12.0 (VERSION) for Microsoft Office Word 2007 (APPLICATION):

image03-2.png

Every item contains a string using the following format:

[%PREFIX%][T%FILETIME%]*\%FILENAME%

%PREFIX% must be one of the following value (otherwise it will be deleted):

[F00000000] “Normal”
[F00000001] “Read Only”
[F00000002] “Pinned to list”
[F00000003] “Read Only and Pinned”

%FILETIME% contains a FILETIME timestamp as a hexadecimal string in uppercase, %FILENAME% contains a path to a file; for example:

[F00000000][T01D1BBF0951A50D0]*C:UsersUserDesktopDocument.doc

For regular users of Microsoft Office, the number of recently accessed files is not one, two, or three, which is more typical of dynamic analysis environments. This fact can be abused as an anti-analysis technique. In order to obtain the number of recent files programmatically, the malicious macro code accesses the RecentFiles.Count property and terminates the execution if the number is less than a preconfigured value.

To bypass this type of evasion and reveal the payload, it’s important that the analysis environment mimics a real user’s machine. This includes, amongst other things, to keep recently accessed documents up to date in a way that is not easy to fingerprint.

Identifying Targets: Abusing GeoIP Information

The second evasion technique exploits a well-known paid service (maxmind.com) for retrieving detailed GeoIP information. Sending a specifically crafted GET request bypasses the user authentication of the site and returns to the client information about continent, country, city, IP address, organization, Internet service provider, time zone, etc. The response text is then compared by the malicious VBA code with predefined values of known analysis environments, such as FireEye, Microsoft, Trend Micro, and others, in order to evade the dynamic analysis in their sandboxes.

The request is sent over HTTPS, which prevents researchers from dissecting, analyzing or creating network-based rules against the network activity (such as rules for specific Response Text, User Agent, Referer, etc.) without resorting to man-in-the-middle (MITM) solutions.

By routing the analysis traffic in a more stealthy way, or by providing users with customizable routing independent of the sandbox vendor, this evasion mechanism can be bypassed, triggering the payload of the attack:

image02-2.png

Another example uses the same evasive mechanism, which drops a slightly different payload, is shown below:

image01-1.png

Abusing Zone Identifiers

Another trick that we have seen in the wild is checking for Zone.Identifier alternative data streams (ADS): Microsoft Windows uses ADS to track metadata of files, such as the origin of a file, to indicate if a file was downloaded from the Internet, was received as an email attachment, etc.

Checking for this ADS metadata provides an effective check against security solutions that capture files independently of a client machine, such as systems intercepting email attachments on the mail server, or when capturing files off the network. These files do not yet contain the ADS information, as it is written by the operating system or application when a client accesses the file. Thus, if a file is captured independently of the client and is sent to a sandbox without adding the ADS, the malicious code can check for the presence of the ADS and determine if the file was received and opened by a real user.

The following snippet of code shows a (deobfuscated) example of how malware reads the Zone.Identifier metadata from its document file ADS:

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Dim strFileName
strFileName = ThisDocument.Path & Application.PathSeparator & ThisDocument.Name
Dim strZoneIdentifier
strZoneIdentifier = strFileName & “:Zone.Identifier”
If Not objFSO.FileExists(strZoneIdentifier) Then Error 101

Fingerprinting Sandbox Users

Checking for the username under which malicious code is running is a well-known evasion technique. Not surprisingly, VBA downloaders started using this mechanism to detect that Microsoft Office is running inside a well-known sandbox.

One of the samples we have looked at for this post checks the %USERNAME% variable against “KR3T” and “PSPUBWS” associated with Hybrid Analysis and Malwr.com services, respectively. Similar to the evasion using MRU files, sandboxes must present themselves as a real user machine without being fingerprintable to expose the malicious behavior.

Summary

VBA downloaders embedded in Microsoft Office documents are a very effective delivery vector for malware because they allow for sophisticated evasion techniques. These techniques complement what we have previously observed in PE files, such as stalling code or checking the presence of analysis tools, with entirely new mechanisms such as using document metadata stored in ADS. The combination of these evasion techniques with sophisticated obfuscation techniques, described in the first part of this blog series, make for a very powerful attack.

One of the key takeaways for bypassing these evasion mechanisms is mimicking a real user’s machine as closely as possible. This includes user information, recently used files, and network connectivity, just to name a few. The creation of a realistic environment allows for the triggering of the malicious payload of these attacks.

Read Part 3 here

Alexander Sevtsov

Alexander Sevtsov

Alexander Sevtsov is a Malware Reverse Engineer at Lastline. Prior to joining Lastline, he worked for Kaspersky Lab, Avira and Huawei, focusing on different methods of automatic malware detection. His research interests are modern evasion techniques and deep document analysis.
Alexander Sevtsov