In February 2022, Microsoft announced that due to how pervasive the use of “weaponized” documents were, they were going to block macros in MS Office documents downloaded from the Internet by default.
Following this announcement, some threat actors sought alternate means for gaining initial access [TA0001] to systems through phishing campaigns, and several settled on the use of disk image files (i.e., files with ISO, IMG, VHD, or VHDX extensions) as, at the time, malware delivered via this means bypassed security restrictions. Then, towards the end of 2022, we started seeing malware, such as Qakbot, delivered via malicious OneNote files.
However, much like the “changes” Microsoft sought to implement, there are settings that organizations can make, via Group Policy Objects (GPOs) or directly via the Windows Registry, to protect themselves, and to significantly inhibit or even obviate attempts to gain initial access. In this short Huntress article, we share some PowerShell one-liners you can deploy with ease to engineer these defences via the Registry. You can copy/paste the PowerShell code provided in this blog post with no modifications, we’ve done all the hard work for you.
Disrupt OneNote Malware
With respect to OneNote files, an option for protecting your infrastructure is simply to remove the OneNote application from endpoints if there is no business use for this application.
If OneNote is required, however, then there are two settings that can be made to endpoints to enhance the security posture and repudiate attacks via files embedded within OneNote files:
Deploying the suggested defences above denies the user the ability to interact with the OneNote malware, raising a dialog box with an error message to contact the IT team (sorry, helpdesk folk), as illustrated in figure 1.
Fig. 1: Error Message Triggered On User Interaction With Malicious OneNote File After Registry Modification
Prevent Automatic Mounting
When threat actors shifted to deploying malware via disk image (ISO, IMG, VHD, VHDX) files, part of the reason they did so was because users could double-click and automatically mount those files, allowing them to immediately access and launch files embedded within those disk image files. Figure 2 illustrates what it looks like when a user automatically mounts a disk image file by double-clicking it, allowing them to execute the contents of the drive, detonating the malware.
Fig. 2: Disk Image File Automatically Mounted
However, settings can be made to prevent users from accessing disk image files in this way, while still allowing them to access disk image files programmatically. The commands to enable those settings are:
With the Registry change implemented, automatically mounting the disk image file via double-clicking is no longer an option, and as such, the image file contents are not automatically available to the user. Instead, the innocuous ‘Disc Image Burner’ is the default option, as illustrated in figure 3, neutralizing the opportunity for the malware to enroll the user in its execution.
Fig. 3: Default Option Following Recommended Defensive Registry Modifications
Macros embedded in MS Office files can be a tricky subject. Some organizations embed macros in Word documents and Excel spreadsheets, and share them via the Internet as part of their legitimate business processes. However, threat actors have used, and continue to use this functionality to gain initial access into enterprise environments. The change in default behavior that Microsoft announced in February 2022 could be implemented as a GPO, or a Registry modification.
In order to disable macros from executing within MS Office (Excel, PowerPoint, Word) files downloaded from the Internet, you can use the below Powershell code to enable the necessary setting. Our suggested PowerShell code will loop through all users and applications, as illustrated in figure 4.
Fig. 4: Powershell Wildcard For Loop Through Each Office Application
Conclusion: Engineering Hostility
Threat actors are well-known for leveraging default behaviors of systems and users to gain access to systems, obtain a foothold and then progress on from there, moving laterally or selling access to other threat actors.
However, the suggested changes in this Huntress article will help make your environment hostile to adversarial attempts for initial access. We have shared and curated some simple steps that you can take that are free, and will serve to transparently increase your security posture, and to significantly frustrate if not halt these attack chains.
Notes on our PowerShell Methods
Elsewhere on the internet there is the suggestion that Office 365 Group Policy templates must specifically be downloaded and imported on a machine, to successfully administer a number of GPO changes to reduce your attack surface here.
On investigation [1, 2], these templates have the GPO point to specific Registry locations anyway, as shown in figure 5. Therefore, it saves time and overhead to directly write these Registry values ourselves and skip importing the templates, cutting out the middle-man as it were.
Fig. 5: OneNote Group Policy .admx Template Lists Direct Registry Key
Moreover, by using PowerShell we gain a number of advantages. First is that we can leverage wildcards to fill in the blanks - meaning we needn’t know or ‘hard-code’ specific Office version numbers or even Office applications. Second, by using PowerShell we do not need every user’s Registry hives to be mounted (as “HKEY_CURRENT_USER”, or “HKCU”) and can instead access each user’s hive via a ‘for loop’ to make the necessary changes. Third and final, by leveraging PowerShell the way we have minimizes the administrator’s effort and maximizes ROI; simply run the PowerShell commands offered to make your environment more hostile to threat actors attempting to gain initial access.