“That sequence matters because it shows deliberate preparation for continued access, not just one-off reconnaissance,” said Ivan Righi, senior cyber threat intelligence officer analyst at ReliaQuest.
ReliaQuest’s 12 May analysis of a resilient ClickFix campaign
ReliaQuest published a blog on 12 May describing an intrusion that combined ClickFix social engineering with PySoxy, an open‑source Python SOCKS5 proxy roughly ten years old. The researchers flagged the case because the tactic did not behave like a simple, one‑time ClickFix execution; instead, attackers prepared and layered tooling so the intrusion could survive removal attempts and endpoint blocks.
PySoxy plus a scheduled task: persistence without traditional malware
In the incident ReliaQuest investigated, the proxy tool included a local persistence mechanism. That mechanism allowed the attackers’ activity to restart through a scheduled task on the host even after defenders blocked initial channels. Blocking the original ClickFix access therefore did not necessarily stop the intrusion, because the scheduled task repeatedly re‑executed proxying components.
Measured staging: reconnaissance, proxying, then payload
ReliaQuest observed a deliberate staging sequence. The intruder first gathered information about the environment, identified follow‑on targets, and confirmed that the host could communicate with attacker‑controlled staging infrastructure. Only after PySoxy successfully established a connection to the attackers’ control server did the intruder introduce the final payload. ReliaQuest’s account emphasizes that the proxy was not dropped immediately after initial access but inserted as part of a planned follow‑on operation.
PowerShell, Python scripts and RAT attempts — and why persistence mattered
Researchers saw attackers try multiple channels to move from proxying to direct control: PowerShell and Python scripts and an attempt to drop a Remote Access Trojan (RAT). Endpoint controls blocked these channels in the observed case, but ReliaQuest notes the persistence mechanism still mattered because it permitted repeated re‑execution attempts. In short, tools that can re‑invoke staging or payload steps turn blocked execution into an ongoing containment challenge.
What this means for response teams, infrastructure providers, and security engineers
- Response teams: Treat ClickFix incidents that include persistence and secondary tooling as active compromises. ReliaQuest advised host isolation, a full artifact review, and validation that “all access paths and staged components have been removed.”
- Infrastructure providers and other organizations: The Australian Cyber Security Centre earlier this month issued a warning about a widespread ClickFix campaign targeting infrastructure providers and other organizations, underscoring that this social‑engineering vector remains an active distribution method for malware and credential theft.
- Security engineers and hunters: ReliaQuest recommended explicit checks beyond blocking observed command‑and‑control connections — review scheduled tasks, analyze Python artifacts, and hunt for proxy‑style Python command lines rather than assuming a blocked C2 equals containment.
Conclusion: ClickFix is evolving; defenders must validate removal
ReliaQuest’s account ties two simple facts into a tougher operational problem: a widely used social‑engineering vector (ClickFix) and an existing open‑source proxy (PySoxy) can be combined and staged so persistence survives routine blocking. The case shows that defenders who stop at a blocked connection risk missing scheduled tasks or Python artifacts that will reinstate access. ReliaQuest’s guidance is concrete: isolate hosts, hunt scheduled tasks and Python proxy artifacts, and verify every access path is gone before declaring containment.
Source: https://www.infosecurity-magazine.com/news/clickfix-combined-pysoxy-proxying/
