Mysterious “Follina” zero-day hole in Office – here’s what to do!

The internet is abuzz with news of a zero-day remote code execution bug in Microsoft Office.

More precisely, perhaps, it’s a code execution security hole that can be exploited by way of Office files, though for all we know there may be other ways to trigger or abuse this vulnerability.

Security researcher Kevin Beaumont has supplied it with the entirely arbitrary name Follina, and given that it doesn’t seem to have an official CVE number yet [2022-05-30T21:00Z], that name looks set both to stick and to be a useful search term.

(Update. Microsoft has assigned the identifier CVE-2022-30190 to this bug, and published a public advisory about it [2022-05-22T06:00Z].)

The name “Follina” was concocted from the fact there’s a sample infected Word DOC file on Virus Total that goes by the name 05-2022-0438.doc. The numeric sequence 05-2022 seems pretty obvious (May 2022), but what about 0438? This just happens to be the telephone dialling code for the area of Follina, not far from Venice in north-western Italy, so Beaumont applied the name “Follina” to the exploit as an arbitrary joke. There’s no suggestion that the malware came from that part of the world, or indeed that there is any Italian connection with this exploit at all.

How does it work?

Very loosely speaking, the exploit works like this:

• You open a booby-trapped DOC file, perhaps received via email.
• The document references a regular-looking https: URL that gets downloaded.
• This https: URL references an HTML file that contains some weird-looking JavaScript code.
• That JavaScript references an URL with the unusual identifier ms-msdt: in place of https:.
• On Windows, ms-msdt: is a proprietary URL type that launches the MSDT software toolkit.
• MSDT is shorthand for Microsoft Support Diagnostic Tool.
• The command line supplied to MSDT via the URL causes it to run untrusted code.

When invoked, the malicious ms-msdt: link triggers the MSDT utility with command line arguments like this: msdt /id pcwdiagnostic ....

If run by hand, with no other parameters, this automatically loads MSDT and invokes the Program Compatibility Troubleshooter, which looks innocent enough, like this:

From here, you can choose an app to troubleshoot; you can answer a bunch of support-related questions; you can perform various automated tests on the app; and if you’re still stuck, you can choose to report the problem to Microsoft, uploading various troubleshooting data at the same time.

Although you probably wouldn’t expect to get thrown into this PCWDiagnostic utility just by opening a document, you’d at least see a series of popup dialogs and you’d get to choose what to do at every step of the way.

Automatic remote script execution

Unfortunately, it looks as though the attackers who discovered the “Follina” trick (or, more precisely, the attackers who seem to have used this trick in various attacks last month, even if they didn’t figure it out themselves) have worked out a series of unusual but treacherous options to put on the MSDT command line.

These options make the MSDT troubleshooter do its job under remote control.

Instead of getting asked how you want to proceed, the crooks have crafted a sequence of parameters that not only cause operation to proceed automatically (e.g. the options /skip and /force), but also to invoke a PowerShell script along the way.

Worse still, this PowerShell script doesn’t have to be in a file on disk already – it can be provided in scrambled source code form right on the command line itself, along with all the other options used.

In this case, the PowerShell was used to extract and launch a malware executable provided in compressed form by the crooks.

Threat researcher John Hammond at Huntress has confirmed, by way of launching CALC.EXE to “pop a calculator”, that any executable already on the computer can be directly loaded by this trick, too, so an attack could use existing tools or utilities, without relying on the perhaps more suspicious approach of launching a PowerShell script along the way.

No macros needed

Note that this attack is triggered by Word referencing the rogue ms-msdt: URL that’s referenced by a URL that’s contained in the DOC file itself.

No Visual Basic for Applications (VBA) Office macros are involved, so this trick works even if you have Office macros turned off completely.

Simply put, this looks like what you might call a handy Office URL “feature”, combined with a helpful MSDT diagnostic “feature”, to produce an abusable security hole that can cause a click-and-get-hit remote code execution exploit.

In other words, just opening up a booby-trapped document could deliver malware onto your computer without you realising.

In fact, John Hammond writes that this trick can be turned into an even more direct attack, by packaging the rogue content into an RTF file instead of a DOC file. In this case, he says, just previewing the document in Windows Explorer is enough to trigger the exploit, without even clicking to open it. Just rendering the thumbnail preview pane is enough to trip Windows and Office up.

What to do?

As convenient as Microsoft’s proprietary ms-xxxx URLs may be, the fact that they’re designed to launch processes automatically when specific types of file are opened, or even just previewed, is clearly a security risk.

A workaround that was quickly agreed upon in the community, and has since been officially endorsed by Microsoft, is simply to break the relationship between ms-msdt: URLs and the MSDT utility.

This means that ms-msdt: URLs no longer have any special significance, and can’t be used to force MSDT.EXE to run.

You can make this change simply by removing the registry entry HKEY_CLASSES_ROOTms-msdt, if it exists. (If it’s not there, then you are already shielded by this workaround.)

If you create a file with a name ending .REG that contains this text…

  Windows Registry Editor Version 5.00    [-HKEY_CLASSES_ROOTms-msdt]  

…you can double-click the .REG file to remove (the minus sign means “delete”) the offending entry.

You can also browse to HKEY_CLASSES_ROOTms-msdt in the REGEDIT utility and hit [Delete].

Or you can run the command: REG DELETE HKCRms-msdt.

Note that you need administrator privileges to modify the registry in this way.

If you discover that you just can’t live without ms-msdt URLs, you can always replace the missing registry data later.

To back up the HKEY_CLASSES_ROOTms-msdt registry key, use the command: REG EXPORT HKEY_CLASSES_ROOTms-msdt backup-msdt.reg.

To restore the deleted registry key later, use: REG IMPORT backup-msdt.reg.

Just for the record, we’ve never even seen an ms-msdt URL before, let alone relied on one, so we had no hesitation in deleting this registry setting on our own Windows computer.

HOW SOPHOS PRODUCTS DETECT AND REPORT THESE ATTACKS

• Sophos endpoint products can detect and block known attacks conducted via this exploit as Troj/DocDl-AGDX. You can use this detection name to search your logs both for DOC files that trigger the original download, and for HTML “second stage” files that follow.
• Sophos endpoint products can detect and block attempts to trigger this exploit as Exec_39a (T1023). These reports will show up in your logs against the program MSDT.EXE in the System folder.
• Sophos email and web filtering products intercept attack files of this sort as CXmail/OleDl-AG.