How to Fix Follina (CVE-2022-30190): Nessus 161691 MSDT Workaround Detection

CVE-2022-30190, known as Follina, is a remote code execution flaw in the Microsoft Support Diagnostic Tool (MSDT) that is triggered through the ms-msdt: URL protocol from applications such as Word. Fix it by installing a Windows cumulative update from June 2022 or later, then deleting the HKEY_CLASSES_ROOTms-msdt key, which is what Nessus plugin 161691 checks.

What the scanner is actually detecting

The finding comes from Nessus plugin 161691, titled “The Microsoft Windows Support Diagnostic Tool (MSDT) RCE Workaround Detection (CVE-2022-30190)”. It is a local check in the Windows family, rated Info, and it needs a credentialed scan with remote registry enumeration (the plugin requires the SMB/Registry/Enumerated KB item).

The important detail is what the plugin does not do. Tenable’s own description says it has not tested for CVE-2022-30190 and is only checking whether the HKEY_CLASSES_ROOTms-msdt registry key exists. In other words, the plugin reports whether Microsoft’s workaround (removing the ms-msdt protocol handler) has been applied. It does not look at patch level.

That creates a common confusion: the plugin’s solution text says to apply the latest cumulative update, but installing the update fixes MSDT without removing the protocol registration. A fully patched host therefore keeps triggering 161691 until the key is deleted. If your scanner reports CVE-2022-30190 through a missing-update check instead, the patching step below is what closes it.

Real-world risk

Microsoft describes the flaw as remote code execution when MSDT is called using the URL protocol from a calling application such as Word. Code runs with the privileges of the calling application, so an attacker can install programs, change data or create accounts within the rights of the user who opened the document. Both Microsoft and NVD score it CVSS 3.1 7.8 (High), with a local attack vector and required user interaction: someone has to open a malicious file.

It was exploited in the wild. CISA added it to the CISA Known Exploited Vulnerabilities catalog on June 14, 2022, with a July 5, 2022 due date for federal agencies. Microsoft shipped fixes in the June 14, 2022 Windows updates and fixed a defense-in-depth variant in the July 2022 cumulative updates.

Put honestly: on a host that has received any cumulative update since mid-2022, the 161691 finding is a hardening gap, not an open RCE. On a host that has missed patching since May 2022 (a forgotten VM, an old golden image, an offline kiosk), it is a known, exploited attack path. Microsoft also notes that Office opens internet-sourced documents in Protected View or Application Guard by default, which blocks the documented attack. A document that a user takes out of Protected View no longer has that protection.

How to confirm it on the host

Is the ms-msdt key present?

From an elevated Command Prompt:

reg query HKEY_CLASSES_ROOTms-msdt /s

If the key exists, you will see it and its shellopencommand subkey pointing at msdt.exe. If it has been removed, reg returns “ERROR: The system was unable to find the specified registry key or value.” In PowerShell, the HKCR hive has no drive by default, so use the provider path:

Test-Path -LiteralPath 'Registry::HKEY_CLASSES_ROOTms-msdt'

Is the host patched?

Check the build and update revision, then compare them with Microsoft’s release information for that Windows version:

Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion' |
  Select-Object ProductName, DisplayVersion, CurrentBuild, UBR
Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 3 HotFixID, InstalledOn

Checking many hosts at once

$hosts = Get-Content .hosts.txt
Invoke-Command -ComputerName $hosts -ScriptBlock {
  $cv = Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion'
  [pscustomobject]@{
    MsMsdtKey = Test-Path -LiteralPath 'Registry::HKEY_CLASSES_ROOTms-msdt'
    Build     = $cv.CurrentBuild
    UBR       = $cv.UBR
  }
} | Select-Object PSComputerName, MsMsdtKey, Build, UBR

How to fix it

Step 1: install the cumulative update

The real fix is patching. Deploy the latest cumulative update for each Windows release through Windows Update, WSUS, Configuration Manager or Intune. Because cumulative updates include earlier fixes, any current CU carries both the June 2022 fix and the July 2022 defense-in-depth change. For Windows 8.1, Server 2012 R2 and older, check the Security Update Guide entry for CVE-2022-30190 for the exact package that applies to your servicing model.

Step 2: remove the protocol handler on a single host

This is Microsoft’s published workaround. Back up the key first, then delete it, from an elevated Command Prompt:

reg export HKEY_CLASSES_ROOTms-msdt C:ProgramDatams-msdt-backup.reg
reg delete HKEY_CLASSES_ROOTms-msdt /f

Run it elevated. As a standard user the delete fails and the key stays, which is a frequent reason the finding “survives” remediation.

Step 3: enforce it fleet-wide with Group Policy Preferences

1. In the Group Policy Management Console, edit a GPO linked to the OUs that hold your workstations and servers.
2. Go to Computer Configuration > Preferences > Windows Settings > Registry, right-click, then New > Registry Item.
3. Set Action to Delete, Hive to HKEY_CLASSES_ROOT and Key Path to ms-msdt. Leave Value name blank and Default unticked so the whole key is removed.
4. Test on a pilot machine with gpupdate /force, then widen the scope.

The Delete action does not keep a backup, so export the key once from a reference machine of each Windows build and store the .reg file with your change record. Because the preference is reapplied on every policy refresh, newly imaged machines lose the key automatically. If the item does not reach some machines, work through troubleshooting GPOs that do not apply before assuming the scan is wrong.

Intune or other endpoint management

For devices not joined to a domain, deploy the same logic as a PowerShell script that runs as SYSTEM (in Intune, do not run it with the logged-on user’s credentials, and use the 64-bit PowerShell host):

$key    = 'Registry::HKEY_CLASSES_ROOTms-msdt'
$backup = 'C:ProgramDatams-msdt-backup.reg'
if (Test-Path -LiteralPath $key) {
    if (-not (Test-Path -LiteralPath $backup)) {
        reg.exe export 'HKEY_CLASSES_ROOTms-msdt' $backup /y | Out-Null
    }
    reg.exe delete 'HKEY_CLASSES_ROOTms-msdt' /f | Out-Null
}
if (Test-Path -LiteralPath $key) { exit 1 } else { exit 0 }

Optional hardening: block Office child processes

If you run Microsoft Defender Antivirus, the attack surface reduction rule Block all Office applications from creating child processes (GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a) targets the same pattern Follina relied on: an Office app launching another process. Start it in audit mode:

Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions AuditMode

Some line-of-business add-ins legitimately spawn processes, so review the audit events and move ASR rules from audit to block mode deliberately. This rule does not clear plugin 161691; it is defense in depth.

How to verify the fix and rescan

1. On a sample of hosts, run reg query HKEY_CLASSES_ROOTms-msdt and confirm the “unable to find” error (exit code 1).
2. Where you used GPP, confirm the GPO is applied with gpresult /r /scope computer.
3. Confirm the build and UBR reflect a current cumulative update.
4. Rescan with the same credentialed Nessus policy. Plugin 161691 should no longer appear. Check that the scan authenticated: without credentials a local registry check cannot run, and “no finding” means “not checked”, not “fixed”.

What can break and how to roll back

According to Microsoft, disabling the MSDT URL protocol prevents troubleshooters from being launched as links, including links throughout the operating system. Troubleshooters remain available through the Get Help app and in system settings. In practice, watch for intranet pages or helpdesk runbooks that launch troubleshooters with ms-msdt: links.

Do not substitute an application control rule that blocks msdt.exe outright. Microsoft’s guidance notes that blocking MSDT prevents all MSDT-based troubleshooters from launching, while the registry workaround only removes link support.

To roll back, first remove or disable the GPP item or the Intune script, otherwise the key is deleted again at the next refresh. Then import the backup from an elevated prompt:

reg import C:ProgramDatams-msdt-backup.reg

If no per-host backup exists, import the export you took from a reference machine running the same Windows build.

Common false positive reasons

• The host is patched. The plugin only tests for the key, so patched machines are still reported. The finding is accurate about the key, not about exploitability.
• The key came back. Reimaging from an older image or rebuilding a machine restores Microsoft’s default registration. Enforce the deletion continuously rather than running a one-off script.
• The delete never ran with rights. A non-elevated reg delete fails with access denied, and a script deployed in user context has the same problem.
• The GPO is out of scope. Security filtering, WMI filters or an OU that the GPO is not linked to leave some hosts untouched.
• Stale results. You are reading a report from before the change, or from a different scan policy.

FAQ

Is plugin 161691 a vulnerability or just information?

Tenable rates it Info. It reports that the ms-msdt handler is registered, which is the precondition Follina abuses. Whether the host is actually vulnerable depends on its patch level.

Why is the finding still open after I installed the latest cumulative update?

Because the update fixes MSDT but leaves the HKEY_CLASSES_ROOTms-msdt key in place. Delete the key, or document a risk acceptance for patched hosts.

Will deleting the key break Windows troubleshooters?

Only the ability to launch them from ms-msdt: links. Microsoft states they can still be reached through Get Help and system settings.

Is MSDT going away anyway?

Microsoft has announced the retirement of MSDT and its legacy inbox troubleshooters in newer Windows releases, with many troubleshooters redirected to Get Help. Older builds still in service keep MSDT, so treat the scan result for each host as the source of truth.

Tracking this finding across many hosts

When plugin 161691 appears on hundreds of machines, the hard part is proving every host closed, not deleting one key. If you use SITEY, you can upload the .nessus export, have its agents deploy an AI-written, human-approved remediation script to the affected Windows endpoints, and then retest each Nessus finding individually to confirm the key is gone. Whatever tool you use, close the ticket on a rescan result rather than on a script’s exit code.

Sources

• Tenable: Nessus plugin 161691
• Microsoft MSRC: Guidance for CVE-2022-30190
• NVD: CVE-2022-30190
• Microsoft Learn: ASR rules reference
• Microsoft Learn: Resources for deprecated features (MSDT)