Recently, we’ve seen reports of malicious files that misuse the legitimate Office object linking and embedding (OLE) capability to trick users into enabling and downloading malicious content. Previously, we’ve seen macros used in a similar matter, and this use of OLE might indicate a shift in behavior as administrators and enterprises are mitigating against this infection vector with better security and new options in Office.
In these new cases, we’re seeing OLE-embedded objects and content surrounded by well-formatted text and images to encourage users to enable the object or content, and thus run the malicious code. So far, we’ve seen these files use malicious Visual Basic (VB) and JavaScript (JS) scripts embedded in a document.
The script or object is surrounded by text that encourages the user to click or interact with the script (which is usually represented with a script-like icon). When the user interacts with the object, a warning prompts the user whether to proceed or not. If the user chooses to proceed (by clicking Open), the malicious script runs and any form of infection can occur.
Figure 1: Warning message prompts the users to check whether they should open the script or not.
It’s important to note that user interaction and consent is still required to execute the malicious payload. If the user doesn’t enable the object or click on the object – then the code will not run and an infection will not occur.
Education is therefore an important part of mitigation – as with spam emails, suspicious websites, and unverified apps. Don’t click the link, enable the content, or run the program unless you absolutely trust it and can verify its source.
In late May 2016, we came across the following Word document (Figure 2) that used VB script and language similar to that used in CAPTCHA and other human-verification tools.
Figure 2: Invitation to unlock contents
It’s relatively easy for the malware author to replace the contents of the file (the OLE or embedded object that the user is invited to double-click or activate). We can see this in Figure 3, which indicates the control or script is a JS script.
Figure 3: Possible JavaScript variant
The icon used to indicate the object or content can be just about anything. It can be a completely different icon that has nothing to do with the scripting language being used – as the authors can use any pictures and any type
Figure 4: Embedded object variant
It’s helpful to be aware of what this kind of threat looks like, what it can look like, and to educate users to not enable, double-click, or activate embedded content in any file without first verifying its source.
Technical details – downloading and decrypting a binary
On the sample we investigated, the contents of the social engineering document is a malicious VB script, which we detect as TrojanDownloader:VBS/Vibrio and TrojanDownloader:VBS/Donvibs. This sample also distinguishes itself from the typical download-and-execute routine common to this type of infection vector – it has a “decryption function”.
This malicious VB script will download an encrypted binary, bypassing any network-based protection designed to recognize malicious formats and block them, decrypt the binary, and then run it. Figure 5 illustrates the encrypted binary we saw in this sample.
Figure 5: The encrypted binary
The embedded object or script downloads the encrypted file to %appdata% with a random file name, and proceeds to decrypt it using the script’s decryption function (Figure 6).
Figure 6: Decryption process
Lastly, it executes the now-decrypted binary, which in this example was Ransom:Win32/Cerber.
Figure 7: Decrypted Win32 executable
Prevalence
Our data shows these threats (TrojanDownloader:VBS/Vibrio and TrojanDownloader:VBS/Donvibs) are not particularly prevalent, with the greatest concentration in the United States.
We’ve also seen a steady decline since we first discovered it in late May 2016.
Figure 8: Worldwide prevalence
Figure 9: Daily prevalence
Prevention and recovery recommendations
Administrators can prevent activation of OLE packages by modifying the registry key HKCU\Software\Microsoft\Office\<Office Version>\<Office application>\Security\PackagerPrompt.
The Office version values should be:
- 16.0 (Office 2016)
- 15.0 (Office 2013)
- 14.0 (Office 2010)
- 12.0 (Office 2007)
Setting the value to 2 will cause the to disable packages, and they won’t be activated if a user tries to interact with or double-click them.
The value options for the key are:
- 0 – No prompt from Office when user clicks, object executes
- 1 – Prompt from Office when user clicks, object executes
- 2 – No prompt, Object does not execute
You can find details about this registry key the Microsoft Support article, https://support.microsoft.com/en-us/kb/926530
See our other blogs and our ransomware help page for further guidance on preventing and recovering from these types of attacks:
- Link (.lnk) to Ransom
- The 5Ws and 1H of Ransomware
- Malicious macro using a sneaky new trick
- New feature in Office 2016 can block macros and help prevent infection
- No mas, Samas: What’s in this ransomware’s modus operandi?
- The three heads of the Cerberus-like Cerber ransomware
- Locky malware, lucky to avoid it
Alden Pornasdoro
MMPC