ReliaQuest spots ClickFix attack using PySoxy proxy

ReliaQuest has identified a ClickFix attack chain that used the open-source PySoxy proxy tool, marking the first time it has seen that combination.

In the incident, attackers used a scheduled task to maintain persistence after a user executed a malicious PowerShell command on a compromised website. The task relaunched the activity about every 40 minutes, allowing the intrusion to keep attempting outbound connections even after security controls blocked command-and-control traffic.

The attack went beyond the one-off execution pattern commonly associated with ClickFix. In the case ReliaQuest examined, the initial user action led to persistence, domain reconnaissance, a PowerShell-based command-and-control channel, and a second access route through PySoxy, a Python SOCKS5 proxy tool that has been publicly available for about a decade.

That gave the attackers two ways to try to maintain access to the host. One relied on a lightweight PowerShell remote access script that polled an external server for tasks every three seconds. The other used Python to open an encrypted proxy connection to attacker-controlled infrastructure over port 443.

How it worked

The activity began when a user visited a compromised site and was prompted to run PowerShell. The command was obfuscated and launched from explorer.exe, a pattern that can make malicious activity appear to come from a legitimate Windows process.

After the first stage executed, the attackers created a scheduled task and placed a staged script in C:\ProgramData. Telemetry reviewed by ReliaQuest showed the task using powershell.exe with arguments including NoProfile, ExecutionPolicy Bypass, and WindowStyle Hidden, which are often associated with low-visibility execution.

Once recovered, the PowerShell script revealed a simple but persistent remote access mechanism. It sent host details, including computer name, username, operating system, and process ID, to an external server, fetched queued commands, executed them in memory, and posted the results back.

The script effectively acted as a remote access tool without requiring a separate malware family. The scheduled task made that access more durable by repeatedly relaunching the script if the process stopped or network controls blocked a connection.

Reconnaissance stage

The attackers also carried out discovery activity on the compromised machine. This included checking group memberships, identifying whether the host was joined to a domain, listing domain controllers, carrying out LDAP-based machine enumeration, and making SMB connections to discovered systems.

Logs were staged locally in C:\ProgramData before being uploaded with curl to attacker-controlled infrastructure. Only after that staging and upload activity did the attackers download the Python bytecode file identified as PySoxy.

One command in the chain ran python.exe against a .pyc file with arguments including -ssl, -remote_port, and -remote_ip. Combined with the earlier PowerShell activity and the use of a non-standard directory, those elements indicated the Python process was being used to create a second route for remote access rather than for routine administration.

Containment challenge

The central issue for defenders is that blocking one outbound connection does not necessarily end the compromise. In the case under review, both command-and-control paths were blocked, but the scheduled task continued trying to restart the malicious script for hours.

That made the attack harder to contain because local persistence remained in place even after network communications were disrupted. ReliaQuest warned that incidents involving ClickFix and secondary tools should be treated as active compromise investigations rather than isolated user-execution events.

Recommended response steps included isolating affected hosts, reviewing scheduled tasks created soon after suspicious PowerShell execution, examining Python artefacts, and hunting for proxy-style Python command lines. Defenders should also review staged PowerShell scripts, Python runtimes, and .pyc files to ensure all components that support re-execution are removed.

The case points to a broader shift in how social engineering-based access can be extended after the initial lure. Rather than relying on a single callback or a known remote management tool, the attackers used built-in Windows functionality, scripting, and an older open-source proxy to create a layered access chain that blended into normal administrative activity.

ReliaQuest urged defenders to watch for sequences in which PowerShell activity is followed by curl downloads, writes to ProgramData, and the launch of python.exe. It also flagged command-line terms such as -ssl, -remote_ip, -remote_port, SOCKS, and .pyc execution as useful indicators when investigating possible PySoxy-related activity.

The infrastructure linked to the activity included IP addresses associated with the ClickFix delivery stage, the PowerShell remote access channel, staging and exfiltration, and the PySoxy proxy destination, along with domains used for the stager and secondary command-and-control traffic.