Malicious AUR Packages Impersonating yay and paru Deliver Root-Level Malware — Detection and Remediation Guide for Arch Linux Defenders

A threat actor has uploaded malicious packages to the Arch User Repository (AUR) impersonating yay and paru — two of the most widely used AUR helper tools in the Arch Linux ecosystem. Because AUR packages are built and installed through makepkg and then installed via pacman with sudo, any malicious logic embedded in a PKGBUILD's build(), package(), or install scripts executes with root privileges. This is not a vulnerability in Arch's packaging infrastructure — it is a classic supply-chain trust-abuse attack, and it works precisely because the AUR model delegates trust to the end user.

If you administer Arch Linux workstations, build servers, or developer endpoints — or if your organization allows engineers to run Arch — you need to treat this as an active incident, not a news item. Foreign packages installed from the AUR bypass the signed, vetted official repositories entirely. A single yay -S <package> on a developer box can hand an attacker root on a machine that likely holds SSH keys, cloud credentials, VPN profiles, and source code.

Why This Attack Works: The AUR Trust Model

The AUR is a community-driven repository. Anyone with an account can submit a PKGBUILD. Arch's own documentation is explicit that AUR content is user-produced and unsupported, but in practice, the convenience of helper tools has trained a generation of users to install AUR packages with the same casual trust they give official repos.

Impersonating yay and paru is an especially nasty choice of target for three reasons:

1. Helpers are force multipliers. Users install an AUR helper early — often as the first foreign package on a fresh system. A malicious helper package lands before any defensive skepticism kicks in.
2. Helpers run constantly. Every subsequent AUR operation flows through the helper. A trojanized helper can intercept, modify, or proxy future package installs — a persistent supply-chain beachhead, not a one-time infection.
3. Typosquatting is trivial. Slightly misspelled or deceptively named packages (extra hyphens, -git suffix confusion, lookalike names) catch users who install by name rather than by inspecting the package page.

The attack chain from a defender's perspective:

1. User searches the AUR (or is directed to a link) and installs the impersonated package via yay -S, paru -S, or manual git clone + makepkg -si.
2. The malicious PKGBUILD or accompanying .install script executes payloads during the build/package phase — often under the invoking user's context during build, then root when pacman -U installs the result.
3. The payload establishes persistence — typically a systemd service or timer, cron entry, or dropped binary in a plausible-looking path — and may beacon out to attacker infrastructure.
4. Because installation ran as root, the malware inherits full system access: credential theft from browsers and SSH agents, keylogging, lateral movement staging — everything is on the table.

Exploitation status: This is confirmed in-the-wild distribution of malicious packages, not a theoretical risk. There is no CVE associated with this campaign — it is abuse of intended AUR functionality, which is exactly why patching won't save you. Detection and hygiene are the entire game.

Detection & Response

The behaviors worth hunting are consistent regardless of the specific payload variant: package builds initiated from AUR helper cache directories, scripts executed from user-writable build paths, and persistence (systemd units, cron) pointing at binaries in unusual locations like ~/.cache, /tmp, or hidden home-directory paths.

Sigma Rules

---
title: AUR Build Directory Script Execution via Helper Cache
id: 3f8c2a71-9b4e-4d1a-b6f2-8e5c7a91d034
status: experimental
description: Detects shell interpreters executing scripts from AUR helper build/cache directories, a strong indicator of malicious PKGBUILD payloads executing during package builds.
references:
  - https://www.bleepingcomputer.com/news/security/fake-arch-linux-packages-push-malware-with-root-privileges/
  - https://attack.mitre.org/techniques/T1195/002/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.execution
  - attack.t1059.004
  - attack.supply_chain_compromise
  - attack.t1195.002
logsource:
  category: process_creation
  product: linux
detection:
  selection_image:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
  selection_path:
    CommandLine|contains:
      - '/.cache/yay/'
      - '/.cache/paru/'
      - 'PKGBUILD'
      - '.SRCINFO'
  condition: selection_image and selection_path
falsepositives:
  - Legitimate AUR package builds that invoke helper scripts during compilation
level: high
---
title: Systemd Service Executing Binary from User-Writable Path
id: 7b2e9d14-5c3f-4a68-b1e9-2d6f8c40a517
status: experimental
description: Detects systemd service units created on disk whose unit files reference executables in user-writable or temporary directories, consistent with malware persistence established by trojanized AUR packages running as root.
references:
  - https://www.bleepingcomputer.com/news/security/fake-arch-linux-packages-push-malware-with-root-privileges/
  - https://attack.mitre.org/techniques/T1543/002/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.persistence
  - attack.t1543.002
  - attack.privilege_escalation
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|startswith:
      - '/etc/systemd/system/'
      - '/usr/lib/systemd/system/'
      - '/run/systemd/system/'
    TargetFilename|endswith:
      - '.service'
      - '.timer'
  filter_legit:
    TargetFilename|contains:
      - '/etc/systemd/system/multi-user.target.wants/'
      - '/etc/systemd/system/graphical.target.wants/'
      - '/etc/systemd/system/timers.target.wants/'
  condition: selection and not filter_legit
falsepositives:
  - Administrators manually creating custom systemd units
  - Configuration management tools deploying services
level: medium

KQL Hunt (Microsoft Sentinel — Syslog/CEF Ingestion)

If you ingest Linux syslog or auditd data into Sentinel, hunt for AUR helper build activity intersecting with root-level process execution and outbound connections from cache directories:

// Hunt: AUR helper build activity followed by suspicious execution or persistence
// Requires Syslog or auditd ingestion from Arch endpoints
let lookback = 14d;
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has_any (".cache/yay", ".cache/paru", "makepkg", "PKGBUILD")
| summarize BuildEvents = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            SampleMessages = make_set(SyslogMessage, 5)
    by Computer, ProcessName
| extend SuspicionScore = iff(BuildEvents > 0 and ProcessName has_any ("sudo", "systemd", "curl", "wget"), 2, 1)
| order by SuspicionScore desc, LastSeen desc;
// Companion query: systemd units referencing user-writable paths (persistence indicator)
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has "systemd"
| where SyslogMessage has_any ("/home/", "/tmp/", "/.cache/", "/var/tmp/")
| where SyslogMessage has_any ("Started", "unit", "service")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL Hunt

Deploy this artifact across Linux endpoints to surface systemd persistence pointing at binaries in user-writable locations — the highest-signal artifact of a root-level AUR malware install:

-- Hunt for systemd services executing binaries from user-writable directories
-- and enumerate foreign (AUR-installed) packages for review
SELECT 
    FullPath AS ServiceFile,
    Btime AS Created,
    Mtime AS Modified,
    read_file(filename=FullPath) AS UnitContent
FROM glob(globs=['/etc/systemd/system/*.service', '/run/systemd/system/*.service'])
WHERE UnitContent =~ '(?i)ExecStart=/home/|ExecStart=/tmp/|ExecStart=/var/tmp/|\.cache'

Companion check for running processes originating from helper caches:

-- Processes executing from AUR helper cache or temp build directories
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Exe =~ '/.cache/yay/|/.cache/paru/|/tmp/'
  AND Username =~ 'root'

Audit and Remediation Script

Run this on any Arch endpoint that uses yay, paru, or manual AUR builds. It inventories foreign packages, flags recently installed ones, and inspects systemd persistence for user-writable paths:

#!/bin/bash
# AUR Supply-Chain Audit — Security Arsenal
# Run as root. Read-only audit; review output before taking action.

echo "=== [1] Foreign (AUR) packages installed ==="
pacman -Qm

echo ""
echo "=== [2] Recently installed packages (last 30 days) ==="
grep "\[ALPM\] installed" /var/log/pacman.log | \
  awk -v cutoff="$(date -d '30 days ago' '+%Y-%m-%d')" '$1 >= "["cutoff"' | tail -50

echo ""
echo "=== [3] Verify yay/paru provenance ==="
for pkg in yay yay-bin paru paru-bin; do
  if pacman -Qi "$pkg" &>/dev/null; then
    echo "--- $pkg ---"
    pacman -Qi "$pkg" | grep -E "^(Name|Version|Packager|Install Date)"
    pacman -Ql "$pkg" | head -20
  fi
done

echo ""
echo "=== [4] Systemd units executing from user-writable paths ==="
grep -rlE "ExecStart=(/home/|/tmp/|/var/tmp/)" /etc/systemd/system/ /usr/lib/systemd/system/ 2>/dev/null

echo ""
echo "=== [5] Recently modified systemd unit files (last 30 days) ==="
find /etc/systemd/system/ -name "*.service" -mtime -30 -exec ls -la {} \;

echo ""
echo "=== [6] Root processes running from cache/temp paths ==="
ps aux | awk '$1=="root" && $11 ~ /\.cache|\/tmp\//'

echo ""
echo "=== [7] Cron persistence check ==="
for u in $(cut -d: -f1 /etc/passwd); do crontab -u "$u" -l 2>/dev/null | grep -vE "^#|^$" && echo "  ^-- user: $u"; done
ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null

echo ""
echo "=== Audit complete. Review sections 4-7 for anomalies. ==="

Remediation and Hardening

Immediate actions for potentially affected systems:

1. Identify and remove impersonated packages. Compare pacman -Qm output against the legitimate package names (yay, yay-bin, paru, paru-bin from known maintainers). Remove any foreign package whose AUR page you cannot verify: sudo pacman -Rns <package>.
2. Assume root compromise on infected hosts. Removal of the package is not remediation. If a malicious PKGBUILD executed during install, treat the host as fully compromised: rotate all credentials accessible from that machine (SSH keys, GPG keys, cloud tokens, browser-stored passwords), audit systemd/cron persistence, and consider a full rebuild. This is standard DFIR posture for root-level malware — don't shortcut it.
3. Check network egress. Review outbound connections from the host around the install window in /var/log/pacman.log. C2 beaconing from a fresh infection often uses common ports (443, 53) with uncommon destinations.

Long-term hardening for Arch users and fleets:

• Always inspect the PKGBUILD before building. yay -G <pkg> or view the package page; read PKGBUILD and any .install files. Look for curl | bash, base64 blobs, unexpected source= URLs, and post-install hooks.
• Check package metadata on the AUR page. Look at the submitter, first-submitted date, votes, and comments. A package impersonating a popular tool with zero votes and a days-old account is a red flag. Orphaned packages that were recently adopted by new maintainers deserve extra scrutiny — account takeover of orphaned packages is a known vector.
• Pin to official repos where possible. yay and paru should be installed from trusted, well-known AUR entries — verify the maintainer against community consensus (Arch Wiki, r/archlinux) before first install.
• Build as an unprivileged user, never root. makepkg refuses to run as root for good reason — never override that. The build phase runs arbitrary upstream code; only the final pacman -U should require sudo.
• Deploy endpoint telemetry on Linux. This campaign is invisible to organizations that only instrument Windows. Forward auditd/syslog to your SIEM, enable process creation logging (auditd rules for execve), and monitor systemd unit creation. Linux developer workstations are high-value, low-visibility targets.
• Govern developer endpoints. If engineers in your org run Arch, define policy: approved AUR packages, mandatory PKGBUILD review, EDR coverage, and network egress filtering. The AUR trust model is incompatible with an unmanaged fleet.

The Bigger Picture

This campaign follows a well-established pattern of supply-chain attacks against community package ecosystems — PyPI, npm, RubyGems, and now repeatedly the AUR. The common thread: ecosystems that optimize for openness and convenience inherit adversaries who exploit exactly that. No vendor patch is coming, because nothing is "broken." The defense is process: verify before you build, instrument your Linux endpoints, and treat any root-executing install script from a community repo as untrusted code until proven otherwise.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub