by Bhabesh Raj Rai, Security Research
Even the most sophisticated and advanced state-sponsored attackers leave digital traces and detecting these anomalies is key to protecting organizations against malware. One common method threat actors use to initiate malware campaigns is by phishing with a malicious Word document. When a user opens the document, it’s likely to trigger the execution of malicious code spawned by a new process. Monitoring how the operating system behaves is critical to detecting this type of attack. An alert that detects if Word suddenly starts a new child process is easy to set up and will provide an early warning, which greatly improves the chances of detecting and stopping attacks. In this blog, we’ll provide tactical advice for how to detect and mitigate malware attacks that use malicious macros.
The use of malicious macros is on the rise
Adversaries have consistently gained initial access by using Microsoft Office macros due to their inherent functionality and flexibility. Threat Intel reports for 2022 indicate that adversaries will continue using macros and show no signs of stopping.
A macro is a command or a set of commands that can automate a set of tasks in Microsoft Office. The concept of software macros has existed since the dawn of the programming language to automate tedious repetitive tasks. Office macros are very powerful and versatile because they can host VBA code, which is one of the main reasons threat actors use macros.
Typically, threat actors attach a malicious macro inside an Office document that they send alongside phishing emails. When victims open the lure document, Office displays a security warning saying that macros have been disabled. By default, Office disables all macros and prompts the user to enable them manually. Threat actors usually include a banner or a picture in the document instructing the recipient to enable macros to correctly view the document. If victims fall for this then the macros usually run Windows shell processes like PowerShell or WScript to download the second-stage payload.
Malicious macros remain within the top 10 detected threats in Reason Lab’s The State of Consumer Cybersecurity 2022. Macros and phishing go hand-in-hand. IBM X-Force Threat Intelligence Index 2022 reports 41% of attacks in 2021 exploited phishing for initial access. Similarly, ProofPoint’s State of Phish 2022 reports a 9% increase in organizations getting targeted by bulk phishing attacks and a 13% increase in spear-phishing attacks in 2021 compared to the previous year.
From 2020, there was a surge in threat actors using Excel 4.0 macros (XLM). XLM macros are the predecessor to VBA macros and were introduced in Excel 4.0. XLM macros provide an alternative to VBA macros with easy access to the underlying OS. Expel’s Great eXpeltations 2022 reports 4% of all ransomware attacks used Excel 4.0 macros. Due to the trend of threat actors abusing legacy, but still supporting XLM macros, Microsoft introduced AMSI instrumentation for XLM in March 2021 and disabled XLM macros by default in January 2022.
Detecting macro activity in Logpoint
When Office’s macro settings are left in their default state, whenever a user enables macro by clicking the “Enable Content” button, Office caches the approval and it auto-approves subsequent openings of the same document. The cache of approved documents is stored in the TrustRecords registry key. Office performs the same action whenever a user enables editing of a protected document. Distinguishing between the two actions is difficult since they require parsing of the last four bytes of binary data written to the registry.
We can configure Sysmon to monitor the registry path to catch changes to the TrustRecords key.
norm_id=WindowsSysmon event_id=13 target_object="*Trusted DocumentsTrustRecords*"
| norm on target_object TrustRecords<path:'S+'>/<file:'[^/]+'>
| process eval("file_d=urldecode(file)")
| rename file_d as file
| chart count() by host, user, image, detail, target_object, path, file
Searching for trusted Office documents via Sysmon
We can do the same search natively using Windows registry auditing. It requires that administrators enable the SACL of corresponding registry keys – HKCUSoftwareMicrosoftOffice\<Word|Excel|…>SecurityTrusted DocumentsTrustRecords.
norm_id=WinServer event_id=4657 object=TrustRecords
| norm on object_value <path:'S+'>/<file:'[^/]+'>
| process eval("file_d=urldecode(file)")
| rename file_d as file
| chart count() by host, user, object, "process", object_name, path, file
Searching for trusted Office documents via Windows registry auditing
Neither Sysmon nor Windows registry auditing provides the binary data that is written to the registry, which we require to distinguish between enabling macros and enabling editing of protected files. We can, however, detect an interesting case of a user enabling editing of a protected document that he might have downloaded from the internet and then enabling macros. Permitting editing and macros will produce two identical log events in a short interval which we can easily implement in Logpoint.
[2 norm_id=WinServer event_id=4657 object_name="*SecurityTrusted DocumentsTrustRecords"
having same host, user, object_name, object_value within 3 minutes]
| chart count() by host, user, object_name, object_value Administrators can configure Microsoft Defender’s Attack Surface Reduction (ASR) rules to detect suspicious Office activities, such as an Office application creating executable files.
norm_id=WinServer event_source="Microsoft-Windows-Windows Defender" event_id IN [1121, 1122]
| process eval("rule=if(rule_id == 'D4F940AB-401B-4EFC-AADC-AD5F3C50688A')
{ return 'Block all Office applications from creating child processes'}")
| process eval("rule=if(rule_id == '3B576869-A4EC-4529-8536-B80A7769E899')
{ return 'Block Office applications from creating executable content'}")
| process eval("rule=if(rule_id == '75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84')
{ return 'Block Office applications from injecting code into other processes'}")
| process eval("rule=if(rule_id == '92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B')
{ return 'Block Win32 API calls from Office macros'}")
| process eval("rule=if(rule_id == '26190899-1602-49E8-8B27-EB1D0A1CE869')
{ return 'Block Office communication application from creating child processes'}")
| chart count() by host, rule, file, path, "process", message
Detecting traces of subsequent macro activity is as important as detecting the initial macro execution. There are many ways for adversaries to create macro payloads for their Office documents. In most cases after macro executions, the child processes are created by the main Office process. Keeping this in mind, administrators can use an awesome sigma rule to hunt for suspicious child processes of Office processes. Logpoint customers can use our Alert Rules package that already contains these types of alerts.
label="Process" label=Create parent_process IN ["*WINWORD.EXE", "*EXCEL.EXE", "*POWERPNT.exe", "*MSPUB.exe",
"*VISIO.exe", "*MSACCESS.EXE", "*EQNEDT32.EXE"]
"process" IN ["*cmd.exe", "*powershell.exe", "*wscript.exe", "*cscript.exe", "*sh.exe", "*bash.exe", "*scrcons.exe",
"*schtasks.exe", "*regsvr32.exe", "*hh.exe", "*wmic.exe", "*mshta.exe", "*rundll32.exe", "*msiexec.exe",
"*forfiles.exe", "*scriptrunner.exe", "*mftrace.exe", "*AppVLP.exe", "*svchost.exe", "*msbuild.exe"]
Adversaries can bypass detection by using WMI to spawn the child’s processes. To hunt for this, we need to look for the execution of Office followed by execution of command shells via WMI. One edge case here is when the user has already opened Office prior to opening the malicious document. A larger time interval on the query can help mitigate this at cost of query performance.
[norm_id=WinServer event_id=4688 "process" IN ["*winword.exe", "*excel.exe", "*powerpnt.exe"]]
as s1 followed by
[norm_id=WinServer event_id=4688 parent_process="*WmiPrvSE.exe" "process" IN ["*cmd.exe", "*powershell.exe"]]
as s2 within 1 minute on s1.host=s2.host
| rename s1.host as host, s1.user as user, s1.process as office_process, s2.parent_process as parent_process,
s2.process as "process", s2.command as command
| chart count() by host, user, office_process, parent_process, "process", command
Searching for macro executing shell processes via WMI
Several Command and Control (C2) frameworks such as Empire and Metasploit provide the functionality to migrate between processes. Adversaries can migrate from the Office processes to a benign one, such as explorer.exe, to avoid detection. Administrators can use Sysmon’s process access events to detect an adversary using Metasploit’s migrate function to inject from WINWORD.exe to another live process such as taskhostw.exe.
norm_id=WindowsSysmon event_id=10 source_image IN ["*winword.exe", "*excel.exe", "*powerpnt.exe"] access="0x147a" call_trace="*UNKNOWN*"
Searching for process injection artifacts by Office processes
Investigating post-compromise macro activity using Logpoint
Administrators can use Logpoint SOAR to create playbooks to investigate adversaries’ post-compromise macro activity.
The investigation playbook includes checking for:
- Spawning of Windows Shell processes by Office processes
- Dropping of EXE/DLL by Office processes
- Triggering of any Office-related ASR rules
- Spawning of Windows shell processes by WMI
- Execution of encoded PowerShell commands
- Process injection by Office processes
Logpoint playbooks investigate post-compromise macro activity
After executing the playbook in Logpoint, we can view the cases created by the playbook’s components in the investigation timeline to get a high-level overview of the investigation’s results.
Logpoint automatically gathers supporting information as part of the investigation
Implementing alert rules to detect macros is essential
We advise administrators to verify their Office macro settings and disable macros altogether if their organization does not use them. Administrators should regularly audit and test their Sysmon configuration to ensure it can satisfy the expected log source requirement of their deployed detections. Having visibility on macro use is paramount in today’s threat landscape due to its continued use by diverse threat actors ranging from ransomware to espionage.
