Command Line Obfuscation Detection

Threat snapshot

Command line obfuscation is one of the most reliable techniques adversaries use to slip past security tooling. By manipulating how commands are encoded and interpreted at the terminal level, attackers can execute malicious payloads while evading signature-based detection that relies on readable command strings. The CHCP command, a legitimate Windows utility for changing the active code page, is a primary enabler of this technique. Calling CHCP before executing a payload alters how the terminal interprets character input, breaking string-matching rules that would otherwise catch the obfuscated command.

The technique is low-cost, widely available in attacker toolkits, and effective against environments that lack deep command-line telemetry. It requires no elevated privileges, no special tooling, and leaves a minimal footprint. It is frequently used as a precursor to PowerShell-based payload delivery, living-off-the-land attacks, and lateral movement scripting. Detection depends on identifying the encoding manipulation itself, before the obfuscated payload executes.

At a glance:

CHCP is the Windows Change Code Page utility. Its legitimate purpose is to set the character encoding used by the active command prompt session. Common code pages include 437 (US English, the default), 850 (Multilingual Latin I), and 65001 (UTF-8). In normal system administration, CHCP is used to ensure correct rendering of non-ASCII characters in terminal sessions.

Attackers exploit this utility by calling it immediately before executing an obfuscated command. Switching the code page to 65001 (UTF-8) or another non-default encoding changes how the terminal processes subsequent character input. Security tools that rely on string matching against the raw command line see a different byte sequence than expected and fail to match known-bad signatures. The obfuscated command passes through undetected.

The attack chain typically follows this pattern: a phishing lure or a compromised script initiates a cmd.exe or PowerShell session, CHCP is called to switch encoding, and an obfuscated payload is passed to the interpreter. The payload may download and execute a remote script, establish a reverse shell, drop a RAT, or perform credential harvesting. Because CHCP is a signed Microsoft binary with a legitimate purpose, its execution alone does not trigger most security tools. The evasion value lies in what follows it.

Attack chain

Real-world scenario

A spear-phishing email lands in a mid-level IT administrator's inbox, appearing to come from the company's software procurement team. The email references an urgent licence renewal and instructs the administrator to run a verification script to confirm their system is eligible for renewal. A PowerShell command is embedded directly in the email body with instructions to paste it into an elevated command prompt.

What the administrator cannot see is that the command first calls CHCP 65001, switching the active terminal code page to UTF-8. This alters how subsequent character input is processed, allowing the obfuscated download cradle that follows to bypass the organisation's endpoint security string-matching rules. With encoding switched, a heavily obfuscated PowerShell invocation downloads and executes a script from an attacker-controlled server.

The payload establishes a reverse shell. Over the next several hours, the attacker uses this access to enumerate Active Directory, identify privileged accounts, and extract cached credentials from LSASS. The CHCP call took less than a second, left no obvious trace in application logs, and was not flagged by the organisation's AV because it involved only a legitimate Windows binary followed by an encoded string that matched no known signature.

Why this happens

CHCP is a native, signed Windows binary. Its execution is routine in system administration contexts, particularly in environments running multilingual applications or scripts. Security tools that do not correlate CHCP execution with its parent process, the calling user context, and what follows the call have no basis to distinguish legitimate use from pre-obfuscation. Without process-creation telemetry tied to command-line content, the technique succeeds silently.

Business impact: What can go wrong

A successful command line obfuscation attack that goes undetected carries significant downstream consequences:

• Credential compromise: attackers who establish post-exploitation access via obfuscated commands routinely target LSASS, browser credential stores, and saved VPN credentials, leading to account takeover across multiple systems.
• Data exfiltration: once remote access is established, sensitive financial, customer, and operational data can be staged and exfiltrated without triggering DLP controls that inspect plaintext content.
• Lateral movement enablement: obfuscation-delivered shells provide a persistent foothold from which attackers pivot to additional hosts, escalate privileges, and extend their reach across the network.
• Ransomware precursor: many ransomware operators use obfuscated command delivery as the initial stage of an attack, using the CHCP technique specifically to defeat endpoint detection before deploying their encryptor.
• Compliance exposure: failure to detect and log obfuscated command execution may constitute a control failure under PCI DSS Requirement 10, NIST CSF DE.CM, and ISO 27001 Annex A.12, triggering breach notification obligations if data is subsequently exfiltrated.
• Reputational damage: if the attack results in a data breach or ransomware incident, the reputational and commercial consequences of having missed a low-sophistication, well-documented evasion technique are compounded.

Indicators of compromise and detection signals

The following signals should be collected and correlated to detect command line obfuscation attempts in your environment:

Prerequisites for detection using Log360

Before Log360 can detect command line obfuscation via CHCP, the following must be in place:

Detecting with Log360

Step 1: Enable the detection rule

Navigate to Log360 > Security > Manage Rules > Rule Library. Search for CHCP Executed. The rule monitors windows_process_started events for execution of the CHCP binary. Enable the rule and save.

Step 2: Tune the Rule

Open the rule configuration and review the following settings before going live:

• Working hours window: set your standard business hours. CHCP executions outside these hours, particularly in the early morning or weekend, should be assigned higher severity automatically.
• Scope: If your environment has dedicated admin jump servers or build systems where CHCP is routinely called by legitimate scripts, add those hostnames as exclusions while rule tuning.

Step 3: Read the Alert

When the CHCP Executed rule fires, the alert surfaces the following fields. Review each in sequence:

Investigating an alert

When a CHCP Executed alert fires, follow these steps to determine whether the execution represents a genuine obfuscation attempt:

• Open the Incident Workbench from the alert panel. Navigate to the affected host and load the process tree for the session window in which CHCP executed. Identify the full parent-child chain: what spawned CHCP, what CHCP spawned, and what processes ran immediately after in the same session.
• Examine the command line of the process that ran immediately after CHCP. Look for: PowerShell invocations with -EncodedCommand, -enc, or -e flags; use of string concatenation ([char] casting, -join, -replace patterns); calls to Invoke-Expression, IEX, or iex; and download cradle patterns such as (New-Object Net.WebClient).DownloadString or Invoke-WebRequest.
• Look for outbound connections from powershell.exe or cmd.exe to external IPs, particularly on non-standard ports or to destinations that do not appear in the host's normal outbound traffic baseline.
• Assess the user context. Query Log360 for the affected user's recent activity: other process creation events, file access events, and email activity if mail logs are forwarded. Determine whether the user is likely to run CHCP legitimately based on their role and past behaviour.
• Determine scope. Search for the same CHCP execution pattern across all endpoints in the last 24 hours. If multiple hosts show the same parent process chain, the activity may represent a scripted campaign rather than an isolated incident.

Escalation trigger

Escalate immediately to L3 if any of the following are observed: CHCP execution followed by an encoded PowerShell command within 60 seconds on the same host; outbound network connection from cmd.exe or powershell.exe to an external IP within 5 minutes of CHCP execution; or CHCP execution under a non-administrative user account with no documented scripting workflow. These combinations represent confirmed or near-confirmed obfuscation attempts.

Responding and remediating

Immediate Containment

• Isolate the affected host from the network using EDR host isolation or by disabling the network adapter via remote PowerShell: Disable-NetAdapter -Name 'Ethernet' -Confirm:$false. This cuts any active C2 channel.
• Disable the affected user account immediately via Active Directory: Disable-ADAccount -Identity [username]. This prevents the attacker from using any harvested credentials for lateral movement while the investigation proceeds.
• Block any external IP addresses identified in the post-CHCP network connections at the perimeter firewall and proxy layer.

Forensic preservation

• Capture a memory image of the affected host before any remediation using WinPmem or your EDR's memory acquisition feature. If a payload executed, its decoded form and any injected code may be recoverable from memory.
• Export the Windows Security event log and Sysmon operational log from the affected host before any reimaging or remediation. These logs are the primary forensic record of the execution chain.
• Preserve the PowerShell script block logging output if enabled (Event ID 4104). This log captures the decoded content of encoded PowerShell commands after the interpreter decodes them, providing the plaintext version of the obfuscated payload.

Eradication and recovery

• Review all persistence mechanisms on the affected host: registry Run keys, scheduled tasks, startup folder entries, and WMI subscriptions. Remove any that cannot be attributed to known, authorised software.
• Force a mandatory password reset for the affected user account and all accounts whose credentials were accessible on the compromised host, including cached domain credentials and service account tokens.
• Reimage the affected endpoint if a payload was confirmed to have executed. Clean-up without reimaging carries residual risk of undiscovered persistence.

False positive guidance

CHCP is a legitimate Windows utility. The following scenarios commonly produce false positive alerts and should be reviewed before escalating:

Key differentiator

A legitimate CHCP execution is isolated. It is called once, with a consistent code page value, by a known parent process, and is not followed by an encoded or concatenated command within the same session. A malicious CHCP execution is always a precursor. If nothing suspicious follows CHCP in the process tree and network logs within 60 seconds, the alert is almost certainly a false positive.

Hardening and prevention

The following controls reduce the attack surface for command line obfuscation techniques in your environment:

• Enable PowerShell Script Block Logging (Event ID 4104) and PowerShell Module Logging across all endpoints via Group Policy. These logs capture the decoded content of encoded PowerShell commands after the interpreter processes them, providing plaintext visibility into obfuscated payloads regardless of the encoding technique used.
• Enable Constrained Language Mode in PowerShell via AppLocker or Windows Defender Application Control (WDAC) policies. This restricts the PowerShell capabilities available to standard users and significantly limits the effectiveness of obfuscated PowerShell payloads delivered via CHCP-based evasion.
• Restrict cmd.exe and PowerShell execution for standard user accounts via AppLocker or Software Restriction Policies where operationally feasible. Most end users have no legitimate need to run command interpreters directly.
• Block or alert on outbound connections from cmd.exe and powershell.exe at the network perimeter or via host-based firewall rules. Legitimate PowerShell administration rarely requires direct outbound internet access from user endpoints.
• Deploy and maintain an up-to-date Sysmon configuration across all endpoints. Sysmon's enriched process creation telemetry, including ParentCommandLine, is essential for correlating CHCP execution with its follow-on commands in a way that Windows Security event logging alone cannot provide.
• Run regular phishing simulation campaigns targeting the specific social engineering technique used in CHCP-based attacks: embedding commands in email bodies with instructions to paste into a terminal. User awareness of this lure significantly reduces the attack surface.

Next Steps

Enable the following related rules in Log360's Rule Library alongside CHCP Executed to build comprehensive coverage of the command-line obfuscation threat chain: