Microsoft has decided to reverse its decision to block Office macros by default. Here’s how to utilize Azure Sentinel to hunt for macro usage within your Organization.
Microsoft has rolled back the changes to block VBA macros until further notice and they haven’t provided any explanations to their customers.
Microsoft Office macros are well-known for being a powerful tool to automate daily tasks and boost productivity. However, macro malware makes use of this feature to infect endpoints.
Macro is known to be sent through email attachments or inside zip files and to remain concealed within Microsoft office documents. These files frequently have official-looking layouts that tempt users to open them. Macro files were designed to launch automatically as soon as they are opened. In recent years, macros have been by default disabled. In order for malware to be executed, malware developers must now persuade users to enable macros.
It was anticipated that their earlier this year decision to automatically block VBA macros downloaded documents would deter attackers from distributing malware.
Before the rollback, the user would see the following notice when they downloaded and opened a document with macro enabled.
Organizations can use some of the mitigation techniques as a result of Microsoft’s decision to roll back.
· Office macros are disabled by default.
· Requiring the signing of office macros before allowing execution
· Only allowing signatures from reliable publications
· limiting the use of office macros to files kept in secure places
· limiting the range of office programs that can execute macros
The attacks could still happen despite the mitigations against macro malware. Threat attackers may employ sophisticated techniques to get around and evade the defenses you have set up. Threat hunting can help you in this situation by allowing you to proactively and iteratively explore the network for any potential sophisticated macro-based threats.
To carry out the threat hunting process, I’ve used Azure Sentinel. Since this was done in a real-world setting, the hunting outcome will remain hidden.
The following is the hunting query
let id=
IdentityInfo
| where TimeGenerated > ago (7d)
| summarize arg_max(TimeGenerated, *) by AccountName
| extend SingedinUser = AccountName
| project SingedinUser, AccountUPN, JobTitle, EmployeeId, Country, City
| join kind=inner (
DeviceInfo
| where TimeGenerated > ago (7d)
| summarize arg_max(TimeGenerated, *) by DeviceName
| extend SingedinUser = tostring(LoggedOnUsers[0].UserName)
)
on SingedinUser
| project SingedinUser, AccountUPN, JobTitle, Country, DeviceName, EmployeeId;
DeviceProcessEvents
| join kind=inner id on DeviceName
| where TimeGenerated > ago (21d)
| where InitiatingProcessFileName == “EXCEL.EXE”
| where InitiatingProcessCommandLine contains “.xlsm” or InitiatingProcessCommandLine contains “.xltm”
| extend Process = InitiatingProcessFileName
| extend Command = InitiatingProcessCommandLine
| project
TimeGenerated,
DeviceName,
SingedinUser,
AccountUPN,
Process,
Command,
JobTitle,
EmployeeId,
SHA1,
SHA256
This search uses three different tables ( Identityinfo, Deviceinfo and DeviceProcess events). A row will be returned for each Accountname if you sort arg max(TimeGenerated, *) by AccountName. Tables have been joined using the join operator.
In conclusion, you can use the aforementioned search to find interesting artifacts in your environment. This search is intended to discover specific processes, including Word ( WINWORD.exe) and Excel (EXCEL.EXE).
