Blocking Fileless Script-based Attacks Using CrowdStrike Falcon®’s Script Control Feature
Fileless and script-based attacks have been low-hanging fruit for years for adversaries, and their versatility has proved effective in sometimes bypassing traditional static-based antivirus solutions. The main reason for why attackers turn to script-based attacks is because they leverage tools or features that already exist in the target environment. For example, attackers have abused existing system tools, such as Windows Management Instrumentation Command (WMIC) and PowerShell, to download malicious payloads within memory or execute commands that bypass or alter security settings.
The CrowdStrike’s Malware Research Center (MRC) team has recently seen spam campaigns using this script-based technique to distribute the BokBot malware. These campaigns leverage legitimate tools such as WMIC and Extensible Stylesheet Language (XSL) files to download the malicious payload.
WMIC can execute locally hosted and remotely hosted XSL scripts directly in memory, a technique commonly known as Squiblytwo. The BokBot banking trojan (also known as IcedID) emerged in April 2017 and is developed and operated by the threat actor LUNAR SPIDER, which CrowdStrike continuously tracks. BokBot has been used against financial institutions worldwide and can augment its capabilities by retrieving additional modules. Over time, BokBot infections have become more prevalent due to distribution campaigns through the Emotet malware (operated by MUMMY SPIDER). Despite the disruption of Emotet’s operations by law enforcement in late January 2021, BokBot still remains a prevalent threat.
CrowdStrike customers are protected from script-based attacks using the CrowdStrike Falcon® platform’s Script-Based Execution Monitoring feature. This blog post describes one of the more recent BokBot distribution campaigns and how the final payload delivery mechanism can be prevented by this feature.
Analysis
BokBot is often distributed through spam campaigns that deliver password-protected ZIP attachments that appear to contain a request document. The password is provided in the email body, and its syntax varies for each campaign. In this case, the attacker provided a 7-digit password (7643564). A Microsoft Word document containing malicious macros is extracted from the ZIP archive, after socially engineering the victim into enabling macros.
The ZIP archive delivered in recent campaigns is called request.zip and contains a Word document that follows a common naming convention (such as specifics.03.09.2021.doc or facts.03.09.21.doc) that has been weaponized with VBA macros, as shown in Figure 1.
Figure 1. Malicious word document containing VBA macros (Click to enlarge)
The VBA macro is obfuscated and uses the AutoOpen() function to execute its malicious code when macros are enabled by the end user, as shown in the Figure 2 code snippet captured using Microsoft Word’s VBA Editor.
Figure 2. Malicious VBA macro code (Click to enlarge)
The aIcbj() function is the main function under AutoOpen() and gets called as soon as the document is opened. As shown in Figure 2, the code is slightly obfuscated. The attacker has hidden malicious data under various text fields in the UserForm’s properties, which contain:
- Strings with hard-coded file paths separated by “|” (the pipe character) and in reverse order
- Strings that contain a malicious script, also in reverse order, that will be written to a disk as a dropped XSL file
In essence, the VBA macro code works as follows:
- Extracts hidden hard-coded string paths in different variables
- Decodes a hidden Base64 string and reverses the output into a variable
- Writes the decoded XML payload to disk as “C:\ProgramData\i.xsl”
- Copies and renames the legitimate Windows “%SYSTEMROOT%\system32\wbem\wmic.exe” binary to “%PROGRAMDATA%\xml.com”
- Calls ShellExecute() with parameter “C:\programdata\xml.com” and “process list /format : “C:\programdata\i.xsl”” to execute the malicious XSL file
Figure 3. Malicious XSL code, as seen in the dropped “i.xsl” file (Click to enlarge)
As shown in Figure 3, the malicious final BokBot DLL will be pulled from a staging URL using an HTTP GET request and saved as “C:\programdata\541.jpg,” which is later executed via regsvr32.exe. At the time of this analysis, the staging URL was unavailable, and we were unable to retrieve the final payload.
Here’s what BokBot’s process execution flow looks like in Falcon Sandbox:
Figure 4. Falcon Sandbox process flow (Click to enlarge)
You can view this BokBot analysis result on our free Hybrid Analysis portal here.
BokBot achieves malicious payload execution by abusing a renamed copy of the legitimate WMIC utility, which will execute a XSL script file. The entire process is outlined below.
XSL Script Processing
XSL script processing is described in the MITRE ATT&CK® framework under ID T1220. Attackers may bypass application control and achieve execution of code by embedding scripts within XSL files. These files contain code that performs formatting on XML files, which means that it can be a way to run code supplied by an attacker. Due to its legitimate functionality, attackers can use XSL to bypass application allowlisting and execute arbitrary code.
Wmic.exe is a command-line utility that comes pre-installed on all versions of Windows and is used to access Windows Management Instrumentation (WMI). An attacker can use the Wmic.exe to invoke the code from an XML file. According to MITRE’s ID T1220, an attacker can also use WMI to perform code execution by using the /FORMAT switch. It’s also worth nothing that Wmic.exe is capable of running code from local or remote XSL files.
Falcon Platform Script Control Feature and UI Toggles for Blocking BokBot
The Falcon platform has a Script Control feature that implements a set of components that provides expanded visibility into a scripting language. This feature looks for scripts and commands that are executed by a script engine, which are subsequently inspected by Script Control. Script Control detects malicious content and prevents execution according to the prevention policies applied to the host.
The Script Control features needed to prevent the BokBot campaign described in this article require the following Script Control and visibility toggles to be explicitly enabled from the Prevention Policy page.
| Toggle | Prevention Policy Category | Description |
| Script-based Execution Monitoring | Enhanced Visibility | When this toggle is ON, Script Control is enabled for any request to scan across the Windows AMSI interface (VBA Macros originating from Microsoft Office applications, VBScript and JScript). This is a visibility setting, and no preventions will occur unless an IOA-based policy option is also enabled. |
| Quarantine and Security Center Registration | Quarantine | This setting is a prerequisite for enabling Script-based Execution Monitoring. When a script file is executed from disk and its content is prevented, Script Control quarantines the script file. |
| Suspicious Scripts or Commands | Execution Blocking | When this toggle is ON, execution of malicious script content is prevented. |
Table 1. Prevention Policy visibility and configuration toggles related to script-based execution
In addition to Script-based Execution Monitoring, options such as Interpreter-Only or Engine (Full Visibility) extend Falcon’s visibility into malicious PowerShell interpreter usage or malicious System Management Automation engine usage by any application, not just from the Windows built-in PowerShell interpreter application. The preventions linked to these two Script Control features are also tied to the Suspicious Scripts or Commands toggle in the Prevention Policy page.
Figure 5. Overview of the Enhanced Visibility category, as seen in the Prevention Policy (Click to enlarge)
When these features are enabled, CrowdStrike Falcon® successfully stops the BokBot malicious document in the early stages of the attack, right when the macro is executed. The prevention kicks in before any malicious payload is even downloaded.
Figure 6. Falcon will prevent the malicious BokBot document when the macro executes, thanks to the extended visibility offered by Script-Based Execution Monitoring (Click to enlarge)
If these features were not enabled, Falcon would have prevented BokBot further down the execution chain by identifying a suspicious execution related to the renamed wmic.exe binary, highlighting a probable masquerading attempt.
Conclusion
Script-based threats such as BokBot and other fileless attacks are on the rise because they can avoid detection from traditional file-inspection-based detection capabilities by leveraging trusted applications that are part of the operating system, and also productivity applications, to interpret and execute malicious script content. When enabled, CrowdStrike’s industry-leading Script Control feature will enhance Falcon’s behavioral capabilities to protect customers from script-based attacks.
Indicators of Compromise (IOCs)
| File | SHA256 |
| Email Attachment | bdca03f1331dc6385b9ec7850723b55223d4761addcedbeb927d86f671e66440 |
| Doc File | 5696a71805e4a4869af440d76a84871a5535efbded6f66ec16a156e26eaa2653 |
| Dropped XSL file | 1f8d59fccfd55c087ce5e177ce8016ca474d0808d45a26dd1c413c7b0d40e0af |
Additional Resources
- Learn about recent intrusion trends, adversary tactics and highlights of notable intrusions in the 2020 Threat Hunting Report.
- Understand the trends and themes that we observed while responding to and remediating incidents around the globe in 2020 — download the latest CrowdStrike Services Cyber Front Lines Report.
- Learn more about the CrowdStrike Falcon® platform by visiting the product webpage.
- Test CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.
