The Dangers of Macros
Around the time Trustworthy Computing was introduced at Microsoft, Scott Culp and his team released a document on TechNet called “The Ten Immutable Laws of Computer Security.” In 2011, Microsoft updated these slightly, but Law #1 remained essentially the same: “If a bad guy can persuade you to run his program on your computer, it’s not solely your computer anymore.”
Unfortunately, for decades, the Office desktop applications have given attackers a playground to exploit law #1 in the form of Office macros. Macros are small, embedded pieces of code stored inside Office documents; these macros can take various actions. Unfortunately, some of those actions can be malicious. Macros are commonly used for all sorts of useful purposes inside company networks, but it’s not a good idea to blindly trust macros that you find in documents downloaded from the Internet—especially given malware expert Kevin Beaumont’s estimate that 25% of all ransomware entry points come from macro execution.
Of course, in general, it is a really bad idea to blindly trust any code you download from the Internet, so Microsoft introduced a feature casually known as “mark of the web” (MOTW) in Internet Explorer and, later, in Windows. MOTW labels downloaded files with an NTFS alternate data stream indicating that the file came from the Internet—that way, a browser or Windows Explorer can do things like scan it with SmartScreen or Defender, or ask you to confirm that you want to execute it, before it opens and starts doing damage. As with Internet Explorer, the Edge browser lets you designate certain sites as trusted, in which case files originating from those sites aren’t labeled with MOTW and thus won’t trigger the usual macro security prompts. This is generally the behavior you want because it doesn’t trigger security prompts when users open files from your intranet. (Unlike IE, Edge makes this decision on a per-site basis instead of forcing you to categorize sites into security zones.)
The great macro flip-flop
Office has generated warnings for files containing macros for a long time now. Users, for the most part, ignore these warnings because they see them so often. To provide better security, Microsoft decided to completely block Office macros in files tagged with MOTW. They announced this change in February 2022, started applying it to preview channels of the Office apps in April 2022 and announced in June 2022 that they would move it to the Current Channel. Pushback from enterprise customers must have been swift and fierce because Microsoft then announced on July 6 that they were going to delay this change for an undefined period. They didn’t say why they were reversing their plans to block macros, which caused quite a bit of (justified) irritation in the security community, nor did they say when they might go back to the original plan.
As of right now, the chart Microsoft published shows that all update channels show a date of “to be determined,” and a separate disclaimer says that eventually, Microsoft will also apply this change to the LTSC branch and to Office 2019, Office 2016, and even Office 2013.
Introducing the Office Cloud Policy Service (OCPS)
While Microsoft figures out what they’re doing with macro execution, the good news is that you can protect yourself now by applying policies to Office apps to block macros. Office has had Group Policy-based controls for macro execution for a very long time, but in today’s world, there’s no guarantee that your users will be using machines that can receive Group Policy; if their computers aren’t domain-joined Windows machines, the GPO settings that control macro execution won’t do any good unless you deploy them using Microsoft Endpoint Manager, which you also may not have.
Thankfully, we have an alternative: the Office cloud policy service (OCPS), which you probably haven’t heard of. OCPS is a web-based tool included with all Office 365 plans that let you define and apply policy settings to Microsoft 365 for enterprise apps through a cloud-based console. When Office client apps authenticate to the service, they query for policy updates, which OCPS will then provide. You can think of OCPS as an Office 365 replacement for the Office administrative templates that Microsoft makes available for use with Group Policy or Endpoint Manager.
The OCPS console is part of the Microsoft 365 apps admin center, which lives at https://config.office.com/. When you log in to the admin center, you’ll probably see two cards, as shown below. You can click Go to Microsoft 365 apps policy management, or you can use the left nav rail to expand the Customization item and then click on Policy Management. Either way, you’ll end up on the Policy configurations page, which will initially be blank.
To control what users can do with macros in downloaded files, you can use OCPS to apply two settings:
- “Block macros from running in Office files from the internet” blocks macros altogether. Users will see a red info bar telling them that macros are blocked, along with a “Learn more” button.
- “VBA Macro Notification Settings” lets you selectively control whether all macros are blocked or whether digitally-signed macros can be run. You can also control whether users can override the block. Because this setting offers more flexibility, it’s also more complex and potentially more dangerous—for now, I’ll just assume you want to block all macros using the “Block macros” setting.
Each of these policy settings can be applied separately, with separate values, for the supported applications: Access, Excel, PowerPoint, Visio, and Word. The VBA Macro Notification Settings policy also can be applied to Project and Publisher. This gives you some welcome flexibility, but it also means that you must ensure that your policies include settings for all those applications.
Blocking macros using OCPS
In most of Microsoft’s other policy-related products, you define a scope that the policy should apply to by choosing things to include or exclude, then you define the policy settings. OCPS makes this process straightforward, although for now, you can only define scopes based on group membership. You can also choose to scope the policy to users who anonymously access documents—which means to provide complete macro-blocking coverage, you’ll need to create two policies.
Start by identifying the Azure AD groups that contain the users you want to apply this policy to. If you don’t already have a suitable group, use the Azure AD portal to create the groups you’ll need.
Once that’s done, do the following:
- Open the OCPS admin center. From the Policy configurations page, click Create.
- Pick a useful, descriptive name for the policy (something like “block macros in downloaded files” would be good) and click Next
- Select the This policy configuration applies to users in the specified group radio button, then use the Add group button to pick the groups that should be in scope for this policy. The result will look something like this (see Figure 2):
- Click Next. That will bring up the Configure Settings page, which starts with a total of 2183 (or more!) policies. To narrow things down you can type “block macro” into the search field, and you’ll see something like this (see Figure 3):
- For each application where you want to block macros, open the policy, and set its state to “Manually configured,” then set the value to “Enabled.” Note that if you instead set the policy state to “Microsoft recommended security baseline,” you’ll get the same result; in this case, the baseline and the explicit policy setting are the same. For clarity, I always prefer to choose the explicit setting instead of the baseline, but this is a matter of personal preference and not a requirement.
- Repeat step 5 until you’ve added all the applications for which you want macros blocked.
- Click Next, then review the final policy configuration. If you’re happy with it, click Create to create the policy.
The policies that you define in OCPS will override the settings you define with the Group Policy ADMX templates (whether those settings are delivered via GPOs or Endpoint Manager). The ADMX settings, in turn, will override any settings that the end-user has applied to her machine in the Office Trust Center. Of note is that these macro policies only apply to Office applications for Windows, not Office on the web, Office for macOS, or Office on Android or iOS.
When do policies take effect?
All OCPS policies are applied when the client pulls them. “When does that happen?” you ask. There are several circumstances in which an Office app will check with OCPS for any policy changes:
- When the user signs into any Office app on a device for the first time
- Every 24 hours for all users
- Every 90 minutes for any user who’s in an Azure AD group that has at least one OCPS policy applied to it
- 90 minutes after a policy change is detected; after a change is applied, the app will poll for changes again in 90 minutes. If there’s another change, it’s applied, and the 90-minute timer restarts. If there are no changes, the next check will be after 24 hours.
The Click-to-Run service running on Windows does the job of querying OCPS, downloading and applying the policy, and keeping track of the timers. Bear in mind that policy changes won’t be instant; when you make a change, you’ll need to build in time for the policy to propagate before expecting it to be enforced.
Moving towards the security baseline
Microsoft has done a really good job of defining security practices for various applications and services over the years. Although it’s been a long journey, “secure by default” was one of the key pillars of Trustworthy Computing, and so it’s good to see the sustained investment and effort of Microsoft’s plan play out.
Part of this journey has been that Microsoft publishes security baselines for various products. The idea is that these baselines provide every customer with a comprehensive, well-documented set of default security policies that they can apply to improve security with relatively little administrative overhead. The Microsoft security team maintains a blog that features regular updates to the baselines for Edge, Microsoft 365 apps, and desktop and server versions of Windows. Of course, there’s a detailed baseline for Microsoft 365 Apps for enterprise, and if you want to get deeper into securing your Office desktop clients, the baseline is an excellent place to start.
In the short term, blocking macro execution is a simple way to significantly improve your security and get you started using OCPS and its wealth of other policy controls.