Inside the AUR Malware Siege: How Arch Linux Volunteers Neutralized a Chaos RAT Attack

The Friday Night Alert

At 5 PM UTC+2 on July 18th, Arch Linux's volunteer security team received alarms about three suspicious packages in the Arch User Repository (AUR): librewolf-fix-bin, firefox-patch-bin, and zen-browser-patched-bin. These packages masqueraded as optimized versions of popular browsers but contained a Remote Access Trojan (RAT). The attacker had already deleted their AUR account and GitHub repository, complicating forensic efforts. Within two hours, the team:

  1. Cloned packages for analysis
  2. Force-deleted malicious content via custom git maneuvers
  3. Disabled associated accounts
  4. Alerted users via official channels

"We tackled the situation in less than two hours... which I think is not bad for volunteers," noted one responder.

The Second Wave Strikes

Just as the team relaxed, a second attack erupted at 10 PM. Packages like minecraft-cracked and vesktop-bin-patched flooded the AUR, uploaded via sockpuppet accounts praising their "quality." The team identified the pattern: all malicious PKGBUILDs contained:

chmod +x "$pkgdir"/opt/$pkgname/patches/main.py

This line executed a "patch" script from deleted Codeberg repositories. By midnight, the team had:

  • Hunted down sockpuppet accounts
  • Confirmed no remaining infected packages
  • Traced the malware to a Command & Control server (130.162.225.47), which fortuitously went offline during analysis

Git Forensics: The Phantom Commits Dilemma

Deleting AUR packages revealed surprising git complexities. Standard deletions leave historical commits accessible via:

git clone https://aur.archlinux.org/malicious-package

The team overwrote packages with minimal valid PKGBUILDs using a custom script. But forensic analysis proved the original malicious commits remained accessible via direct commit SHA access—a risk illustrated when examining firefox-patch-bin:

Article illustration 2

Malicious commit persisting in cgit despite deletion

Purging these required dangerous repository-wide garbage collection: 

git reflog expire --expire=now --all
git gc --prune=now --aggressive

"Doing this on the AUR machine would impact all packages... not something we’d experiment with for commits users can’t find anyway," the team concluded.

Anatomy of the Chaos RAT Infection

The malware employed sophisticated techniques to maximize damage:

  1. Social Engineering: Packages used provides=() fields to appear as legitimate alternatives during installation
  2. Evasion: Post-install scripts bypassed build chroots, executing as root
  3. Staging: A Python downloader (main.py) fetched systemd-initd—a Go binary Chaos RAT
  4. Persistence: Systemd services ensured boot survival

Dynamic analysis revealed the RAT phoned home to 130.162.225.47:8080, displaying:

┌────────────────────────────────────────────┐
│              CHAOS (dev)                   │
│        130.162.225.47:8080                │
└────────────────────────────────────────────┘

The "dev" tag suggested sloppy deployment. VirusTotal confirmed Chaos RAT capabilities: full system control, DDoS, and cryptomining.

Lessons from the Trenches

This incident highlights critical truths about open-source ecosystems:

  • Volunteer Velocity: Despite no 24/7 staffing, Arch's team contained threats in hours
  • AUR's Double-Edged Sword: The provides=() field and script execution enable both convenience and exploitation
  • Immutable Infrastructure Risks: Git-based packaging leaves historical attack surfaces
  • Vigilance Over Convenience: As one responder warned: "Remember that AUR packages are user-produced content... always inspect packages before installing!"

The Chaos RAT campaign ultimately failed—thanks to vigilant users reading PKGBUILDs and rapid volunteer response. But as supply chain attacks escalate, this event serves as both a blueprint for community defense and a stark reminder: trust must be compiled, not assumed.

Source: Arch Linux Security Team analysis published at mh4ckt3mh4ckt1c4s.xyz