PyStoreRat profiles systems, deploys multiple payloads, alters execution paths when EDR tools like CrowdStrike Falcon are detected.

Khushal

Level 13
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
601
3,604
1,169
🤖 A new wave of AI-generated supply-chain attacks is emerging, and it’s targeting the people who research, build, and secure our technology.

Morphisec Threat Labs has uncovered a coordinated malware campaign hiding in plain sight on GitHub. Dormant accounts were reactivated, polished “AI-built” repos were published, and after they gained traction, attackers quietly injected a previously undocumented backdoor: PyStoreRAT.

PyStoreRAT isn’t just another loader. It profiles systems, deploys multiple payloads, alters execution paths when EDR tools like CrowdStrike Falcon are detected, and uses rotating C2 nodes for persistence.



1765544570340.png
 
🤖 A new wave of AI-generated supply-chain attacks is emerging, and it’s targeting the people who research, build, and secure our technology.

Morphisec Threat Labs has uncovered a coordinated malware campaign hiding in plain sight on GitHub. Dormant accounts were reactivated, polished “AI-built” repos were published, and after they gained traction, attackers quietly injected a previously undocumented backdoor: PyStoreRAT.

PyStoreRAT isn’t just another loader. It profiles systems, deploys multiple payloads, alters execution paths when EDR tools like CrowdStrike Falcon are detected, and uses rotating C2 nodes for persistence.



View attachment 293691
This is a good example of how “AI-generated” projects + GitHub trust can turn into a very effective supply‑chain attack, especially against researchers and IT/OSINT folks.

Key risk points from what you posted
  • Dormant GitHub accounts get reactivated and polished, AI-looking projects appear “professional” and useful.
  • Once the repo gains traction/stars, attackers quietly add a backdoored update (PyStoreRAT).
  • The malware profiles the host, can drop multiple payloads, and changes behavior when EDR (e.g. CrowdStrike) is present.
  • Rotating C2 / infrastructure makes takedown and IOC‑based detection harder.

I haven’t read the full Morphisec paper directly, so I can’t speak to all their specific findings, but this fits a pattern we’re already seeing with “open‑source + AI + dormant accounts” being abused.

Practical defenses for devs, researchers and OSINT people

  • Treat GitHub projects like untrusted binaries. Especially “new” tools that:
    • Appear suddenly with a big initial commit
    • Come from accounts with long dormancy or little prior reputation
    • Push large updates right after gaining stars/mentions
  • Don’t run new tools on your main workstation. Use:
    • Isolated VMs or disposable lab machines
    • Separate OS accounts with limited privileges
    • Containers for CLI tools where possible
  • Pin and vendor dependencies. Use lock files (e.g. requirements.txt, poetry.lock, etc.), and prefer vendoring critical libs so a repo update can’t silently swap in malicious code.
  • Audit before you trust. At minimum:
    • Skim setup/installer scripts and any “bootstrap” files
    • Look for obfuscated strings, strange networking code, or dynamic eval/exec/reflection
    • Check commit history for a “suspicious last update” that adds networking/crypto/system APIs
  • Verify the project’s identity.
    • Check if the repo is linked from an official website, conference talk, or known researcher profile
    • Be cautious with “AI-powered” tools with no real‑world references or community around them
  • Lock down outbound traffic.
    • Restrict interpreters (Python, PowerShell, Node, etc.) from making arbitrary outbound connections on sensitive systems
    • Monitor new, unusual domains or IPs, especially shortly after installing a new tool
  • Use least‑privilege everywhere.
    • Don’t give new tools full‑disk access, domain creds, or long‑lived API tokens
    • Segment high‑value assets and admin workstations from where you test new tools

If you suspect you ran a compromised repo

  • Immediately disconnect the machine from the network (wired + Wi‑Fi + VPN).
  • Run full scans with one or more reputable AV/EDR products.
  • Check for new scheduled tasks, services, startup items, or unusual user accounts.
  • Export logs (EDR, Sysmon, firewall) for later analysis before wiping anything.
  • Rotate credentials used on that system (passwords, SSH keys, cloud/API tokens, VPN certs).
  • For high‑value or domain‑joined systems, strongly consider a clean OS reinstall / reimage.

Good next step
I’d recommend going through the full Morphisec PDF you linked for their IOCs and technical details, then turning those into internal detection rules (SIEM, EDR custom rules, YARA, etc.).

If you’re comfortable sharing (without anything sensitive), which type of tools/repos you rely on most (Python OSINT scripts, recon frameworks, etc.), people here can suggest concrete hardening ideas tailored to that stack.
 
This campaign represents a significant evolution in supply chain tradecraft, specifically targeting the very professionals tasked with securing infrastructure. The use of dormant GitHub accounts that are reactivated to publish polished, AI-generated repositories creates a veneer of legitimacy that can easily deceive even experienced analysts. By burying the malicious "maintenance" commits after the repositories have gained traction, the attackers effectively weaponize the trust inherent in the open-source community.

The technical sophistication of PyStoreRAT is evident in its adaptive execution logic. The malware’s ability to profile the endpoint and alter its launch path upon detecting EDR solutions like CrowdStrike Falcon or ReasonLabs indicates a high level of operational security awareness.This is not a "spray and pray" commodity threat, it is a targeted tool designed to ensure persistence and facilitate the deployment of secondary payloads, such as the Rhadamanthys stealer, without triggering immediate alarms.

Defenders must look beyond standard signature detection and focus on behavioral anomalies, particularly regarding Python environments and HTA execution chains.The malware's reliance on a rotating command and control infrastructure, specifically using nodes like `node{i}-py-store` and `py-installer`, complicates network-level blocking. Security teams should actively hunt for unexpected Python processes initiating network connections to these naming patterns and scrutinize any recently adopted open-source tools for unverified commit history.

This incident serves as a stark reminder that code provenance is critical. You must verify the history and maintainer activity of any repository before introducing it into your environment, regardless of its apparent popularity or polish. Isolate development environments from production assets to limit the blast radius of such compromises, and ensure your endpoint protection policies are configured to alert on the specific anti-analysis behaviors exhibited by this threat.