Windows - Security - Mitigate Message Queuing RCE Vulnerabilities

What the MSMQ RCE mitigation Worklet does

This Automox Worklet™ mitigates Microsoft Message Queuing (MSMQ) remote code execution vulnerabilities on Windows endpoints. The Worklet stops the MSMQ service, sets its startup type to Disabled, and adds an inbound Windows Firewall rule that blocks TCP port 1801, the listener exploited by the QueueJumper vulnerability (CVE-2023-21554) and a wider cluster of MSMQ flaws disclosed in 2023 including CVE-2023-36910, CVE-2023-36581, CVE-2023-36431, and CVE-2023-35349.

The Worklet applies Microsoft's two recommended mitigations in a single policy run. The service-stop and Disabled startup type remove the in-process attack surface. The named firewall rule "AUTOMOX WORKLET: Block TCP 1801" severs network reachability to the MSMQ listener even if the service is later re-enabled by another administrator or a build script.

MSMQ is an optional Windows feature commonly installed on legacy .NET application servers, BizTalk hosts, and older line-of-business workstations. The service is enabled by default on endpoints that previously required it and is rarely audited afterwards. If your environment does not actively run queued messaging, this Worklet finds and remediates the MSMQ exposure across every Windows endpoint under Automox management.

Why mitigate MSMQ remote code execution risk

QueueJumper (CVE-2023-21554) is a pre-authentication remote code execution vulnerability in the MSMQ message-parsing path with a CVSS score of 9.8. An attacker who can reach TCP 1801 on a Windows endpoint can send a single crafted message and execute code in the context of the Message Queuing service, which runs as NT AUTHORITY\SYSTEM by default on both workstation and server SKUs. Microsoft's November 2023 Patch Tuesday added more than a dozen additional MSMQ RCE and information-disclosure CVEs in the same component, confirming that the MSMQ listener remains an active attack surface.

QueueJumper and the related MSMQ flaws are reachable from any network segment that can route TCP 1801, which on most enterprises means every Windows host that ever installed BizTalk Server, a legacy .NET work queue, or a COM+ queued component. Applying the service-disable and port-block sequence through a single Automox policy run reaches the MSMQ host in a regional office, the BizTalk server in a colocation facility, and the developer workstation that still has the feature enabled. The mitigation persists across reboots because the firewall rule and service start mode are stored in the registry.

How MSMQ mitigation works

1. Evaluation phase: The Worklet calls Get-Service -Name MSMQ to determine whether the Message Queuing service is installed. If the service is not present, the endpoint is reported compliant and the script exits 0 without scheduling remediation. If the service exists, the Worklet inspects Status and StartType, queries Get-NetTCPConnection -LocalPort 1801 for an active listener, and runs Get-NetFirewallRule -DisplayName 'AUTOMOX WORKLET: Block TCP 1801' to confirm the block rule exists and is enabled. The endpoint is flagged non-compliant (exit 2) if the service is running, the StartType is anything other than Disabled, an active listener is detected on TCP 1801, or the firewall rule is missing or disabled.

2. Remediation phase: The remediation script runs Stop-Service -Name MSMQ -Force followed by Set-Service -Name MSMQ -StartupType Disabled, which stops the active process and prevents the service from restarting at boot. It then calls New-NetFirewallRule -DisplayName 'AUTOMOX WORKLET: Block TCP 1801' -Direction Inbound -Protocol TCP -LocalPort 1801 -Action Block to create the inbound block rule. If a rule with that display name already exists but is disabled, the script uses Set-NetFirewallRule -DisplayName 'AUTOMOX WORKLET: Block TCP 1801' -Enabled True to re-enable it. The script exits 0 on success and writes Write-Error with exit code 1 if any step fails.

MSMQ mitigation requirements

• Windows 8 or later, Windows Server 2008 or later (Windows 10, Windows 11, and Windows Server 2012 through Windows Server 2022 are all supported)

• PowerShell 5.0 or later with the NetSecurity and NetTCPIP modules available (default on supported Windows versions)

• The Automox agent running with local administrator context, which is the default install

• Windows Defender Firewall enabled on the affected profile so the block rule takes effect

• Confirmation that no production application on the endpoint depends on MSMQ (BizTalk, legacy .NET workers, COM+ queued components) before scheduling the policy at fleet scale

Expected MSMQ state after remediation

After a successful run, Get-Service MSMQ reports Status: Stopped and StartType: Disabled, and Get-NetTCPConnection -LocalPort 1801 returns no listener. Get-NetFirewallRule -DisplayName 'AUTOMOX WORKLET: Block TCP 1801' returns an Enabled inbound rule with Action Block on TCP 1801. The Worklet does not uninstall the MSMQ Windows feature; if you want to remove the binaries from disk, follow up with a separate policy that runs Disable-WindowsOptionalFeature.

Subsequent Automox policy runs report the endpoint as compliant without re-running remediation, because the evaluation phase finds the service disabled, the port closed, and the firewall rule in place. To validate at the network layer, run Test-NetConnection -ComputerName <endpoint> -Port 1801 from a peer host and confirm the result is TcpTestSucceeded: False. For audit evidence, capture the output of Get-Service MSMQ, Get-NetFirewallRule -DisplayName 'AUTOMOX WORKLET: Block TCP 1801' | Format-List *, and the Automox activity log entry, and attach them to the MSMQ remediation ticket. The mitigation persists across reboots and Windows feature updates because the firewall rule and service start mode are stored in the registry, not in volatile state.