Search results for:
By: Shiran Grinberg
How hackers use malicious Office files and Social Engineering to execute code and install payloads
Macros are special-purpose programs used to automate procedures within a bigger application or software. Usually a macro consists of a series of commands and actions written in a dedicated Macro Language or a standard programming language. These commands will be executed automatically by the application when a certain trigger takes place.
Macros are implemented extensively within Office Suites to allow the automation of common tasks and procedures. Different suites use different macro languages, but some notable mentions are Visual Basic for Applications (MS Office), LibreOffice Basic (LibreOffice) and OpenOffice Basic (OpenOffice).
Most Office macro languages have rather extensive features and can access various resources. For example, MS Office macros (written in VBA) can run executables and use networking capabilities.
This is part of an extensive series of guides about Network Attacks
As with any program allowing the execution of customizable scripts in the background, attackers can exploit Office suites to run malicious code and compromise victims. Usually the macro-malware acts as a loader in the infection chain, and will download and execute another payload before terminating.
The malware will be embedded in – you guessed it – an Office file, and implanted somewhere for the victim to access it, say a common file share or by e-mail. Once the file is opened, the malware will be executed. This is called a Spearphishing Macro Attack (MITRE T1193: Spearphishing Attachment[1]), and it’s been prevalent for a very long time.
One memorable example of a macro-malware is the Melissa virus, which first appeared in 1999. The malware was embedded in an MS Word file and when opened, would e-mail itself to the first 50 contacts in the victim’s address book. Though it didn’t cause much damage to individual users (aside from accidentally causing several mail services to DDOS), the total worth of damages caused was estimated at 80$ million, and the attacker was sentenced to 20 months in federal prison.
But that is not to say that spearphishing macro attacks are a remnant of days past. According to data gathered by Cofense Intelligence[2], during the month of August 2018, malicious macros embedded in MS Office files accounted for 45% of all malware delivery mechanisms analyzed. Moreover, despite the seemingly amateur nature of such attacks, the malwares were used to deliver some of the most malignant payloads in circulation – including Geodo, Chanitor, AZORult and others.
Spearphishing methodologies have also been used in complex APT attacks by various groups, including several that are believed to have links to espionage agencies[3], [4]. In some more sophisticated attacks, legitimate office files were replaced with malicious, seemingly identical ones[5].
So why would attackers worldwide, including advanced hacking groups, opt to use an attack mechanism that hasn’t changed much since the 90’s?
In today’s ever-evolving defense landscape, spearphishing attacks rely on a unique vulnerability, and one that is very hard to mitigate completely – human error. The adversary waits for certain actions to be taken by the victim (say, opening a file) to gain execution, rather than on vulnerabilities that are dependent on the victim’s machine alone (see MITRE T1204: User Execution[6]).
Furthermore, MS Office macro-execution is usually either enabled by default or is allowed by a single mouse click upon opening the malicious file. This creates a large margin for user error and increases the probability of a successful attack.
Relying on user execution also allows adversaries to target and lure non-technical users specifically, compromising entire enterprises through them. But mitigation is still possible, as we’ll see below, by implementing proper endpoint defense mechanisms as well as educating users.
Here is an example of a common MS Office macro lures, as gathered by Microsoft’s Threat Intelligence Center over the summer of 2016:
Figure 1: Common “Created in a Newer Version” Lure
One of the main risks of macro viruses is their ability to spread quickly. Once the malware is executed, it can embed itself in other Office files on the victim’s machine or even into the Office file templates themselves, rendering every document created on the machine compromised. As the malware spreads, more and more legitimate files are compromised and the margin for user error increases.
Moreover, because macros are written in a macro-language and are executed as part of a bigger program, they are largely cross-platform compatible, making their spreading even easier.
Macro-malwares are relatively easy to obfuscate. Obfuscation tools are readily available online, and malicious code snippets can be even taken out of the macro source code and hidden in other file components like text labels, Excel cells etc. to evade detection.
Macro threats can be designed to live “off the land”, meaning they don’t write anything to the disk and only use common tools to run code directly in memory. This technique has risen in popularity in the past years and was explained fully in this blog post.
LOL binaries, libraries and scripts can be used exclusively to create entirely Fileless Malware, or be incorporated with traditional techniques to create hybrid attack vectors that write some files to the hard drive.
As with many user execution methodologies, macro attacks have a low entry-threshold to be executed successfully. Macro-malwares are rather easy to operate and require minimal tweaking to specific victims (if any), in exchange for being highly-dependent on social engineering techniques.
In this demonstration we’ll create a malicious MS Office file using Metasploit on a Kali Linux machine, but other note-worthy tools are Empire, Evil Clipper, LuckyStrike and Magic Unicorn.
We will use Metasploit to generate malicious macro-code that will load the reverse_https payload upon execution. Once up and running on the victim’s machine, this payload will initiate an HTTPS connection with our attacking machine (handled by a separate Metasploit terminal), allowing further exploitation.
We’ll start the Metasploit console by typing msfconsole and then switch to the reverse_https sub-console by using the command use windows/meterpreter/reverse_https.
Figure 2: “reverse_https” payload sub-console in Metasploit console
The console options can be seen by typing show options:
Figure 3: “reverse_https” sub-console options
Now we will set the host and port the payload will try and connect with when executed. We set our Linux machine’s local IP address and a random port. Also, we will set the payload to migrate to a new process when initiating a session by setting a migration script to run automatically post-execution:
Figure 4: Setting our payload’s host, port and other options
Now we will generate the payload in VBA format using generate -f vba -o <filename>
Figure 5: Generating the payload code in VBA format and outputting to file
On a separate terminal, we will set-up a handler to listen for HTTPS requests from the victim’s machine. Once established, we will have a CNC interface with the victim. As before, a host, port and payload to listen to will be set:
Figure 6: Setting-up a handler on a separate Metasploit terminal
And now the handler can be run:
Figure 7: The handler is running and listening for HTTPS requests for 192.168.1.29
On a Windows machine, we will open our MS Office application of choice. We opted for MS Word. First, we will open the Macros window by clicking View -> Macros:
Figure 8: MS Office toolbar on Windows 10 machine, showing the “Macros” button to the right
In the Macro Window, we will click Create and paste the contents of payload.vba in the VBA editor that will open:
Figure 9: Naming and creating a new macro
Figure 10: Inserting our malicious code in the VBA editor
Now everything is set up (aside from tailoring the document to lure a specific victim). Once the file is opened, either the macro will execute automatically or the victim will be prompted to enable macros with the “Enable Content” Button:
Figure 11: When opening our malicious file, the victim is prompted to enable macros
Spearphishing attempts rely on user execution and human error to pan out. Because of this, one of the most efficient strategies to mitigate risk is limiting the use of macros across an organization.
If an organization doesn’t use macros, they might as well be disabled altogether. But that isn’t always the case. When macro use is essential, policy should be set to minimize exposure to attacks (on Windows this may be accomplished through the Group Policy Editor). This can be done in two complementary forms:
An attack surface is the total number of ways or places in which an adversary may compromise a device or network. In the context of macro-malware, the capabilities, resources and COM objects VBA macros have access to can be altered in order to reduce the attack surface.
Cynet actively reduces endpoints’ attack surface by restricting access to resources that are essential for malware to operate. Of these rules and restrictions, here are some that specifically target Office macro attacks:
As with other file-based malware, malicious macros (which are essentially code-files embedded in an Office file) can be detected and signed by Cynet’s products. For example, a macro may be deemed malicious if it:
However, as threats are growing ever more obfuscated and complex, a need for more sophisticated detection techniques has risen. Starting from Windows 10, Microsoft added a new component called Anti-Malware Scan Interface (AMSI) to address this concern. Microsoft’s AMSI acts as an interface between script interpreters and anti-virus engines, allowing them more control over macro execution than ever before.
Among various detection mechanisms, Cynet also uses Windows’s AMSI to scan Office applications’ memory buffer and other data at runtime, and thus enhances its ability to detect malicious macros and behaviors significantly. Finally, if the macro’s behavior is assessed malicious, its execution will be halted, the application session will be shut down, and the user will be prompted with a notice.
Diligently utilizing AMSI’s capabilities, Cynet can detect and prevent obfuscated attack vectors in numerous runtime environments, including Powershell, Windows Script Host, JavaScript, VBScript and VBA.
(To learn more about how Cynet can protect from spearphishing attempts, click here)
In this article
Let’s get started
Ready to extend visibility, threat detection and response?
Prefer a one-on-one demo? Click here
By clicking next I consent to the use of my personal data by Cynet in accordance with Cynet's Privacy Policy and by its partners
