CVE-2021-38647

What it actually does

CVE-2021-38647 is an authentication-bypass remote code execution flaw in Microsoft Open Management Infrastructure (OMI), the Linux management agent deployed by several Azure and Microsoft monitoring, automation, diagnostics, and operations products. A remote attacker can send a crafted WS-Management request to the OMI service without a valid Authorization header and invoke privileged management methods such as shell-command execution. Because OMI commonly runs with root privileges, successful exploitation can result in unauthenticated root-level command execution over the network, leading to full confidentiality, integrity, and availability compromise of the affected Linux host.

Why it matters to the business

This vulnerability can allow an external attacker to take complete control of affected Linux systems used for monitoring, automation, diagnostics, or cloud operations without needing credentials. Because it is known to be exploited in the wild, appears in CISA KEV, has a very high EPSS score, and has been associated with ransomware activity, unpatched systems present an urgent risk of service disruption, data theft, cryptomining, lateral movement, and ransomware deployment. The broad use of OMI through Azure-related agents and management products increases the likelihood that organizations may be exposed even if they did not knowingly install OMI directly.

How an attack unfolds

An attacker first identifies a Linux system exposing the OMI WS-Management service, commonly over TCP 5985, 5986, or 1270, or through an Azure management/monitoring agent that installed OMI. The attacker sends a crafted SOAP/WS-Man request to the /wsman endpoint that omits authentication but requests a privileged OMI operation, such as SCX_OperatingSystem ExecuteShellCommand. Vulnerable OMI versions fail to require authentication for that request path and execute the supplied command as the OMI service account, typically root. The attacker then uses the initial command execution to download tooling, establish persistence, create additional accounts or SSH keys, run cryptominers, disable defenses, collect credentials, pivot to other systems, or stage ransomware. Public exploitation has been observed since disclosure, and the vulnerability is listed in CISA KEV with a remediation due date of 2021-11-17, indicating confirmed real-world exploitation.

How to fix it

Upgrade Microsoft Open Management Infrastructure to a fixed release, generally OMI 1.6.8.1 or later, or install the latest vendor-provided updates for the Microsoft product that deployed OMI. Update all affected Azure and Microsoft components that bundle or depend on OMI, including Azure Automation State Configuration, Azure Automation Update Management, Azure Diagnostics for Linux, Azure Security Center/Microsoft Defender for Cloud integrations, Azure Sentinel/Microsoft Sentinel components, Azure Stack Hub integrations, Container Monitoring Solution, Log Analytics Agent, and System Center Operations Manager Linux agents. Where immediate patching is not possible, restrict network access to OMI ports TCP 5985, 5986, and 1270 to trusted management sources only, block internet exposure, and disable or remove OMI if it is not required. Restart OMI and dependent agents after patching to ensure the fixed binaries are active. Because exploitation grants root-level access, systems confirmed or strongly suspected to be compromised should be treated as fully compromised and rebuilt or restored from trusted sources after credential rotation.

How to confirm the fix worked

Confirm the installed OMI package version is 1.6.8.1 or later, or the latest version supplied by the relevant Microsoft/Azure agent package. On Linux systems, validate with package-manager queries such as rpm -qa | grep -i omi, dpkg -l | grep -i omi, or checking omiserver/omi package metadata. Confirm that OMI services have been restarted after patching and that the active process is using the updated binary. Validate exposure by scanning for listening services on TCP 5985, 5986, and 1270 and confirming access is limited to approved management networks. A safe validation should avoid executing arbitrary commands; instead, verify version and configuration state and confirm unauthenticated WS-Man requests are rejected. Review vulnerability scanner results and cloud security posture findings for remaining OMI detections across all Linux hosts and agent-managed workloads.

Typical attack path

1. Scan for exposed OMI/WS-Man services on TCP 5985, 5986, or 1270, or identify Linux hosts running Azure monitoring, diagnostics, automation, or management agents.
2. Send a crafted unauthenticated SOAP request to the OMI /wsman endpoint invoking a privileged method such as SCX_OperatingSystem ExecuteShellCommand.
3. Execute a simple command to validate code execution and determine privilege level, commonly as root.
4. Download and run a second-stage payload using curl, wget, bash, Python, Perl, or similar tools.
5. Establish persistence through cron jobs, systemd services, SSH keys, new users, or modified shell profiles.
6. Perform post-exploitation actions such as credential collection, internal scanning, lateral movement, cryptomining, data staging, or ransomware deployment.
7. Attempt to remove traces by deleting shell history, temporary files, dropped payloads, and relevant service logs.

How to detect it

Investigate historical exploitation by correlating network, host, and OMI-specific telemetry. Review firewall, load balancer, packet capture, proxy, and flow logs for inbound connections to TCP 5985, 5986, or 1270, especially from unknown internet sources, followed by outbound connections to download sites, paste services, mining pools, or unfamiliar infrastructure. Inspect OMI logs such as /var/opt/omi/log/omiserver.log and related files under /var/opt/omi/log/ for WS-Man requests, SOAP actions referencing ExecuteShellCommand, SCX_OperatingSystem, or requests with missing/invalid authentication. Use EDR or Linux audit logs to identify omiserver or omiengine spawning shells or utilities such as bash, sh, curl, wget, Python, Perl, chmod, chattr, crontab, systemctl, useradd, or ssh-keygen. Examine /tmp, /var/tmp, and /dev/shm for recently created executable files, scripts, miners, or staging artifacts. Check for persistence through new cron entries, suspicious systemd units, modified SSH authorized_keys files, new local users, and altered shell startup files. Because public exploitation often involved automated scanning and commodity payloads, absence of a single known malware hash is not sufficient; focus on the behavioral chain of unauthenticated OMI access followed by root-level command execution and payload retrieval.

• /var/opt/omi/log/omiserver.log
• /var/opt/omi/log/
• /etc/opt/omi/
• /opt/omi/
• /var/opt/omi/
• POST /wsman
• ExecuteShellCommand
• SCX_OperatingSystem
• http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem/ExecuteShellCommand
• omiserver
• omiengine
• omiserver -> /bin/sh
• omiserver -> /bin/bash
• omiengine -> /bin/sh
• omiengine -> /bin/bash
• omiserver -> wget
• omiserver -> curl
• omiengine -> wget
• omiengine -> curl
• tcp/5985
• tcp/5986
• tcp/1270
• /tmp/
• /var/tmp/
• /dev/shm/
• /etc/cron.d/
• /var/spool/cron/
• /etc/systemd/system/
• authorized_keys

What your security team should do

• Immediately identify Linux systems running OMI or Microsoft agents that bundle OMI, prioritizing internet-facing systems and systems reachable from untrusted networks.
• Patch or upgrade OMI to 1.6.8.1 or later, or the latest Microsoft-supported agent version, and restart affected services.
• Block or tightly restrict inbound access to TCP 5985, 5986, and 1270 wherever OMI is present; these ports should not be broadly exposed.
• Hunt for prior exploitation using OMI logs, web/proxy/firewall telemetry, process execution logs, EDR data, shell history, cron/systemd changes, and suspicious child processes spawned by omiserver or omiengine.
• Treat confirmed exploitation as root compromise: isolate the host, preserve evidence, rotate credentials and secrets accessible from the host, and rebuild from a trusted image where feasible.
• Search for persistence mechanisms commonly deployed after Linux RCE, including new users, SSH authorized_keys additions, cron entries, suspicious systemd units, and files in /tmp, /var/tmp, and /dev/shm.
• Review ransomware and cryptomining indicators because this vulnerability is listed in KEV and marked as used in ransomware campaigns.
• Add SIEM detections for unauthenticated or unusual OMI /wsman requests, ExecuteShellCommand SOAP actions, and command interpreters or download utilities launched by OMI processes.
• Ensure asset inventories account for OMI installed indirectly through Azure diagnostics, monitoring, automation, Sentinel, Security Center/Defender for Cloud, Log Analytics, SCOM, and container monitoring components.