Windows - Security - Mitigate CVE-2022-47966

What the CVE-2022-47966 mitigation Worklet does

This Automox Worklet™ contains active exploitation of CVE-2022-47966 on Windows endpoints that may run Zoho ManageEngine ServiceDesk Plus, ADSelfService Plus, ADManager Plus, Endpoint Central, or any of the roughly two dozen ManageEngine products that bundle the vulnerable Apache Santuario XML signature library. The root cause is an outdated Santuario release that lets an unauthenticated attacker forge a SAML response and reach remote code execution against the ManageEngine web tier. The Worklet does not patch the application itself; it closes the network path attackers use to reach it.

The script drives Windows Firewall with Advanced Security to create inbound block rules on TCP 80 and TCP 443, the two ports every ManageEngine console listens on by default. It then writes inbound and outbound block rules for the 15 IP addresses CISA published in joint advisory AA23-250A as confirmed threat actor infrastructure for this campaign. Every rule the script creates is tagged with a DisplayName that starts with [ AUTOMOX WORKLET ], so a responder can enumerate, audit, and revert them once the vendor patch lands.

Brief the operational impact before scheduling. The script starts the Windows Firewall service if it is stopped and enables the Public profile if no firewall profile is currently active. Inbound TCP 80 and 443 blocks apply globally, so any other web service hosted on the same Windows endpoint (IIS sites, custom listeners, monitoring agents) becomes unreachable from the network until the rules are reverted. The Worklet accepts a Revert parameter that removes the rules it created and restores the prior firewall posture once you have patched ManageEngine and verified clean logs.

Why mitigate CVE-2022-47966 before the patch window closes

CVE-2022-47966 is a CVSS 9.8 unauthenticated remote code execution flaw in the Apache Santuario library bundled with ManageEngine products that have SAML single sign-on configured or previously enabled. CISA, the FBI, and MS-ISAC issued joint advisory AA23-250A after observing nation-state and ransomware actors weaponize the bug within days of public disclosure. Public exploit code is mature and embedded in commodity toolkits, which means any internet-reachable ManageEngine console with a vulnerable Santuario version is a candidate for opportunistic compromise.

The vulnerable services run under SYSTEM, so a successful exploit hands the attacker the Windows host, then frequently the domain through the privileged service accounts ManageEngine uses to query Active Directory. Shadow installations are common in mid-size environments where individual teams deployed a free tier years ago and never inventoried it. Containing the network path on every Windows endpoint in scope buys time to identify, patch, and validate each ManageEngine build against the fixed-version table in the Zoho advisory.

How the CVE-2022-47966 firewall mitigation works

1. Evaluation phase: The evaluation script exits 0 unconditionally so remediation always runs when invoked. This pattern is intentional for an emergency containment Worklet: it is designed to be triggered through FixNow or a one-shot policy when an admin decides the endpoint needs network isolation, not as a recurring compliance check.

2. Remediation phase: The remediation script confirms the Windows Firewall service (mpssvc) is present and exits 2 if it is not. It starts the service if it is stopped, then queries Get-NetFirewallProfile and enables the Public profile when no profile is active. It calls New-NetFirewallRule to create two inbound TCP block rules for ports 80 and 443, then iterates the hard-coded list of 15 CISA-published IPs and creates an inbound and outbound block rule per address (32 rules total). Each rule carries the DisplayName prefix [ AUTOMOX WORKLET ]. When the Revert parameter is set to true, the script walks the same port and IP lists, finds the matching block rules, and removes them with Remove-NetFirewallRule.

CVE-2022-47966 mitigation requirements

• Windows Server 2012 R2 or later, or Windows 10/11, with the Automox agent installed and running under the LocalSystem context

• PowerShell 5.1 or later with the NetSecurity module available (default on supported Windows builds)

• Windows Firewall service (mpssvc) present on the endpoint; the Worklet starts it if it is stopped and exits 2 if the service is absent

• Administrative privileges to call New-NetFirewallRule and Set-NetFirewallProfile (the Automox agent context already meets this)

• Awareness that inbound TCP 80 and 443 are blocked globally on the endpoint, not just for ManageEngine, until the Revert parameter is run

• Parameter Revert (boolean, default false): set to true on a follow-up run to remove the firewall rules created by this Worklet and restore the previous network posture

• Vendor patch on hand: confirm each target ManageEngine build matches the fixed-version table in the Zoho advisory before reverting

Expected firewall posture after mitigation

After the remediation run, the endpoint shows 32 new firewall rules in Windows Defender Firewall with Advanced Security. Two are inbound TCP blocks on ports 80 and 443; 15 are inbound IP blocks for the CISA threat actor list; 15 are matching outbound IP blocks for the same list. All 32 carry the DisplayName prefix [ AUTOMOX WORKLET ], so they are easy to enumerate from PowerShell with Get-NetFirewallRule -DisplayName '[ AUTOMOX WORKLET ]*'. The Windows Firewall service is running, at least the Public profile is enabled, and any ManageEngine console listening on the default ports is unreachable from the network.

Run a short validation pass after the policy completes. From an admin PowerShell session on the endpoint, run Get-NetFirewallRule -DisplayName '[ AUTOMOX WORKLET ]*' | Measure-Object and confirm the count is 32. From a separate workstation, run Test-NetConnection -Port 443 against the endpoint and confirm it fails. Check the Automox activity log for the policy run and confirm exit code 0 with no PowerShell exceptions. Once the vendor patch is applied and the ManageEngine build is verified clean, run the Worklet again with Revert set to true, then re-run the Get-NetFirewallRule check and confirm the count is back to zero.