ASR rule “Block Win32 API calls from Office macros”

Microsoft says it’s fixed. It may be, but I think there’s more to it than meets the eye.

Colleagues of mine noticed that, aside from shortcuts disappearing, Defender also started acting up on TortoiseProc.exe from TortoiseSVN. Notably, checkouts would fail and files would be “caught” (and reported) by Defender. Not only that, but once the rule had been set to audit as an immediate workaround, the problem stopped.

That raised an eyebrow, I have to admit.

But let’s first take the facts we know apart a bit. The rule is named “Block Win32 API calls from Office macros”¹ — emphasis mine. Now wouldn’t this suggest that the rule is scoped to (Microsoft) Office only? To me it would.

The InTune documentation states:

This rule prevents VBA macros from calling Win32 APIs.

Office VBA enables Win32 API calls. Malware can abuse this capability, such as calling Win32 APIs to launch malicious shellcode without writing anything directly to disk. Most organizations don’t rely on the ability to call Win32 APIs in their day-to-day functioning, even if they use macros in other ways.

[…]

Dependencies: Microsoft Defender Antivirus, AMSI

Well, having formerly worked as an admin, I think this is a sensible rule and also an appropriate scope for the rule. But that’s that AMSI thing?

Well, that acronym stands for Antimalware Scan Interface. I don’t recall when exactly it was introduced, but it’s been around for years and I remember it being introduced. Having worked for FRISK Software, subsequently Commtouch, then renamed to Cyren, I fell into the second group of audience at the time:

The Antimalware Scan Interface is designed for use by two groups of developers.

• Application developers who want to make requests to antimalware products from within their apps.
• Third-party creators of antimalware products who want their products to offer the best features to applications.

The goal of AMSI is to enable the scanning of “scripts” in the widest sense for antimalware products. Or as Microsoft currently phrases it²:

Windows components that integrate with AMSI

The AMSI feature is integrated into these components of Windows 10.

• User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
• PowerShell (scripts, interactive use, and dynamic code evaluation)
• Windows Script Host (wscript.exe and cscript.exe)
• JavaScript and VBScript
• Office VBA macros

Now, I don’t know the exact scope and would doubt that generally JavaScript gets subjected to the AMSI treatment — say from within your browser — but I also haven’t validated that assumption using the reverse engineer’s tool chest 😉. Either way, we notice that AMSI is tightly integrated with Windows in several places and that apparently Office VBA macros are one area. We can also deduce from the public documentation³ that a COM interface needs to be implemented to tap into AMSI.

So what the hell does all of this have to do with TortoiseProc.exe? Well, the connection between the events in TortoiseProc.exe and Defender appeared to have a direct causal link. What could TortoiseProc.exe possibly be doing that triggers AMSI?

Well, I’ll venture a guess, or rather a few; but first let’s establish some of the basics.

For starters we have to understand that making a COM server available for automation, such as from those components mentioned in the list above, a client has to implement the IDispatch interface. Furthermore we should understand that .NET was originally dubbed COM+ and some of the metadata stored in PE files⁴ is used by the Common Language Runtime; the runtime which drives the .NET Framework and Core. Furthermore some of the metadata format used for previous versions of COM has been extended and is now known as WinMD. Last but not least there is tight coupling between COM and .NET to this day and much of the functionality used by “modern apps” is implemented in the form of COM servers. So the gist is: COM is old and very important.

In order to instantiate a coclass (concrete class) offered for a given interface by a registered COM server, you have a few “entry points” such as CoCreateInstance. That would seem like an ideal way to hook for AMSI, don’t you think?

And now my first guess …

AMSI uses this approach to peek into processes that load COM servers implementing the IDispatch interface across the board⁵.

If this were the case and the rule set changed in a way that inadvertently widened the scope of what the ASR rule “caught” from, say, — Office VBA macros — to anything AMSI has introspection for, this would very much explain why suddenly the rule affected seemingly innocent software. And moreover software that definitely would not be suspected of running Office VBS macros.

Interestingly when taking a look, we can find that TortoiseProc.exe does make use of IDispatch transiently through its use of EnvDTE, the automation component of Visual Studio⁶.

Now for my second guess …

Even if neither IDispatch or EnvDTE are involved it stands to reason that AMSI integrates with COM in various ways. Any boring old Win32 software would find third-party code loaded into its process if it used certain “shell” controls or facilities, such as the open/save dialogs. Because there is a thing called shell extensions, which allows COM servers to interface with, well, the “shell” — and that’s Windows Explorer and the facilities on which it is built.

So, something as mundane as right-clicking within an open/save dialog could cause an InProc-COM-Server⁷ to be loaded into it. And that is typically implemented by third parties which in turn could make use of other COM servers, some of which — to come back to the first guess — may implement IDispatch.

With all we know and some educated guesses, it may well be that Microsoft truthfully fixed the issue, but the fact that it occurred suggests that AMSI introspection that goes much further than Microsoft’s official description suggests. From this it stands to reason that the issue may turn up in the future — again under the inconspicuous label AMSI — but affected by another AMSI-related rule than this time.

// Oliver

1. GUID: 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b [↩]
2. same as previous link [↩]
3. there may be more available to participants of MVI … [↩]
4. .exe, .dll, … [↩]
5. whether this had been introduced with the latest patch Tuesday or otherwise is beyond the scope of my guess … [↩]
6. as a side note, it also appears that TortoiseSVN implements IDispatch in its own SubWCRev class; but I did not dig enough to assess whether it was the EnvDTE dependency or SubWCRev that subjected TortoiseProc.exe to AMSI scrutiny [↩]
7. InProc is a shorthand for “in-process”, meaning a DLL loaded into said process [↩]