Inside the AUR attack: ghost accounts, poisoned commits and a server hidden in the Tor network

About this attack you have read the same thing almost everywhere: how many packages were involved, which credentials were stolen, which wallets were drained. The inventory of loot.

It is the least useful part of the story.

The loot tells you what you lost. It does not tell you why losing it was possible, and above all it does not tell you whether it can happen again tomorrow. To know that you have to look at the mechanism: the exact sequence of steps that leads from an update command typed absent mindedly to an SSH key in someone else's hands. That is what we try to reconstruct here, step by step, with the public references that let you verify every link.

Let us start with something almost everyone took for granted.

They did not breach the official Arch Linux repositories. They did not compromise pacman, the official distribution servers or the signatures of the packages maintained by the project.

They did something simpler: they exploited users' trust in the Arch User Repository, better known as the AUR.

The AUR is a community platform where people publish mainly PKGBUILD files, that is, scripts that tell the system how to download, compile and install a program. The problem is structural, not accidental: while the package is being built, these files can run commands on the user's computer. If someone takes control of one and adds a malicious command, it is the user who launches the attack while believing they are updating an ordinary piece of software.

No one broke into anything. The victim ran the code willingly, with their own privileges, convinced they were doing routine maintenance.

The chain, in seven moves

Before going into detail it helps to have the map, because the strength of this operation lies precisely in the fact that each single step, taken in isolation, looks legitimate:

1. take control of a package, adopting it if orphaned or creating a brand new one;
2. modify the install script by adding an executable with an innocuous name;
3. before doing anything, the executable checks that it is not being watched;
4. if the coast is clear it installs itself so as to survive reboots;
5. it downloads a Tor client and disguises it as a system process;
6. through Tor it retrieves the real malware from an untraceable server;
7. the malware harvests credentials and tries to spread over SSH to reachable machines.

Each of these steps deserves a close look, because that is where you see the difference between an improvised attack and a designed one.

The first alarm

The story does not begin at the end of July.

On 11 June 2026 researchers at Sonatype had already identified a campaign called Atomic Arch. The attackers adopted AUR packages left without a maintainer and modified their install instructions, making them download malicious npm dependencies such as atomic-lockfile, js-digest and lockfile-js.

The first estimates spoke of a few hundred packages. As the investigation progressed, Sonatype pointed to roughly 1,500 packages potentially involved across the various waves. Arch Linux had reacted by temporarily limiting registrations, package creation, adoptions and updates.

At the end of July, though, the attackers came back. And they had learned something.

This time they did not just pull in an easily recognizable malicious dependency, the thing that anyone who reads a PKGBUILD carefully can spot. They started planting genuine Linux ELF executables inside the packages, often with innocuous names like validator, converter, parser, optimizer, hasher or bundler.

The leap is subtler than it looks: a suspicious dependency name takes ten seconds to look up on a search engine. A binary called validator inside a project that actually validates something raises no eyebrows.

The commit that reopened the case

The first confirmed case of the new wave appeared on 29 July 2026 in the AUR package openconnect-sso, a wrapper used to connect to corporate VPNs through SSO authentication. Note the choice of target: whoever installs a corporate VPN client is, in all likelihood, someone with access to a corporate network.

A comment posted on the package page warned users not to install the latest version and reported that a file called validator was being run through sudo.

From that moment, independent researchers and community members began taking the file apart piece by piece.

The first stage analyzed was a Linux x86-64 executable of about 43 KB. Its public SHA-256 hash is:

2d25d2ea313767fae5808164224cf6ad610ab09546d1e5a6f033eedbfd98a281

The program did not start by stealing data straight away. First it checked the environment: it looked for debuggers, sandboxes, hostnames typical of malware analysis labs and at least 25 variables associated with CI/CD platforms like GitHub Actions, GitLab CI, Jenkins and CircleCI.

In other words, the first question the malware asked itself was not "what can I steal" but "is anyone watching me". If the answer was yes, it did nothing. That is why campaigns like this stay invisible for so long: they behave perfectly in front of exactly the people looking for them.

A hidden backdoor behind dbus-daemon

Once past the checks, the loader copied itself into a hidden directory using a randomly generated name. If it had the necessary privileges it could settle under /var/lib, otherwise it operated inside the user's home directory.

To survive reboots it created systemd services, enabled "linger" to keep the user's services running even after logout, and added cron jobs set to run automatically at startup. Three different mechanisms for the same purpose: if an administrator finds one and removes it, the other two remain.

Then comes the most interesting part of the infrastructure.

The malware downloaded a Tor client from the official Tor Project archive, prepared a local configuration and started it while changing the name shown in the process list. The command handed Tor the apparent name dbus-daemon, imitating one of the most common and legitimate processes on a Linux system.

Stop for a moment on this detail. How often, looking at the output of ps, have you paused on dbus-daemon? That is exactly the point: the disguise is not trying to be invisible, it is trying to be boring.

Once Tor had finished connecting to the network, the loader used the local SOCKS proxy to reach an .onion address embedded directly in the binary. From that server it downloaded an archive containing the second stage, saved initially as /dev/shm/.agent.bin or in the /tmp directory.

Saying the attackers "published an onion" does not mean they registered a traditional domain. An .onion address is derived cryptographically from the service key and is distributed through the Tor network. The real server only makes outbound connections to the relays, hiding its own location and IP address. Without an operational mistake by the attacker, physical seizure of the server or data from the provider, tracing the operator can be extremely hard.

And here the architectural choice reveals the intent: separating the first stage from the real payload means that even when the community finds and analyzes the file uploaded to the AUR, the actual malware stays out of reach, on a server nobody knows the location of and whose contents can change at any moment.

The second stage: stealer, RAT and SSH worm

The final payload was much larger: a Rust binary of about 3.6 MB, also compiled for Linux x86-64.

Its public SHA-256 is:

06c857c8ca798d50c765b4de39e6c4f272ecb57bc8316a8ed4c0fdf02fb59502

The analysis describes it as a combination of three tools:

• an infostealer, designed to steal information;
• a RAT, that is, a remote control system;
• an SSH worm, able to try to spread to other machines.

The malware looked for browser passwords, cookies and sessions; data from 1Password, Bitwarden and LastPass; wallets such as Exodus, Electrum, Ledger and Trezor; tokens for Discord, Slack and Telegram; AWS, Azure, Google Cloud and Kubernetes configurations; GitHub and GitLab credentials; .env files; Vault tokens; API keys for artificial intelligence services; GPG keys and, above all, private SSH keys.

It also read known_hosts, the file that holds the addresses of servers the user has already connected to. Using the stolen keys, it could try to copy itself onto the other machines through scp and start itself remotely with ssh.

It is worth spelling out what this means. known_hosts is not a credential file, it is a convenience: it exists to avoid the warning about the server fingerprint. Nobody treats it as sensitive. But placed next to the private keys it becomes the map: on one side the keys, on the other the list of doors they open. The malware does not even have to hunt for targets, we have already catalogued them for it.

A single developer's laptop thus becomes the entry point to corporate servers, cloud environments, production systems and CI/CD runners.

Communications with the command center went through Tor and a further encrypted protocol based on X25519, HKDF and ChaCha20-Poly1305. A fixed X25519 public key was also identified in the second stage, which can be used as an indicator to link together samples belonging to the same infrastructure.

The last packages and the removed commits

On 30 July a user of the official Arch mailing list posted a first list of packages in which suspicious executables had been found. Among them were:

archutil/linter, boringssl-git/hasher, icloudpd/preprocessor, stirling-pdf-desktop-bin/optimizer, windscribe-cli-v2-bin/parser and magic-context-dashboard-bin/validator.

Robin Candau, a member of the Arch Linux DevOps team, replied saying he had banned the accounts responsible and reverted the malicious commits.

The next day more packages were reported, including i915-sriov-dkms, warp-terminal-git, weather-display, astro-box, rtk-git and several dozen minor projects. Arch said it had acted on these too.

On 1 August a package tied to Pandoc also surfaced, published by the account alicemarty, which included a suspicious file called bundler. Candau confirmed its removal.

On the same day another 19 packages were reported and, shortly after, a second batch of 27. Among the more sensitive names were debtap-bin, hexchat-bin, aurutils-bin, paru-git, linux-cachyos-bin, openssl-1.1-bin, gtk2-bin and grub-customizer-bin.

One detail changes the initial reconstruction, and it is the most important point of the whole affair: Candau explained that at least the batch of 19 packages was not made up of old orphaned projects freshly adopted. They were brand new packages, uploaded on purpose by the attackers.

On 30 July Arch Linux had disabled the adoption of orphaned packages. The attackers simply stopped adopting and started creating. On 1 August, seeing that the attack was continuing, the team blocked all pushes to the AUR entirely.

It is the sequence that tells more than any binary analysis: the defense closed one door and the attack opened another within hours, which means someone was following the countermeasures in real time and deciding how to get around them. Not an automation launched and forgotten, but a person at work.

The last verifiable public status I found dates to 2 August: pushes were still disabled and the team gave no date for reopening.

Many malicious commits can no longer be viewed normally today because they were reverted or because the whole package was deleted. The mailing list, however, preserves names, timestamps, suspicious accounts and executable names, effectively becoming a kind of public forensic record of the incident.

The ghost accounts

Two names surfaced publicly: alicemarty, tied to the Pandoc package, and zelmaandersen.

The second account had been created using a temporary email address and had adopted python-airtable-wrapper without yet publishing an update. A community member flagged it preemptively and the Arch team suspended it.

It is an important trace, but it is not an identity.

Account names can be made up, email mailboxes can be temporary and the author data set in Git commits can be forged. On this last point it is worth being clear, because it is a widespread misconception: the name that appears as the author of a commit is a text field you set yourself, not proof of identity. In the June campaign, commits had already appeared that seemed to come from known maintainers, even though those maintainers had not actually done the push.

To attribute the attack you would need non public information: IPs used to create the accounts or upload the commits, AUR access logs, full email addresses, any browser fingerprints, provider data and links to other criminal infrastructure.

Who might be behind it?

There is, for now, no public attribution to a person, a known criminal group or a government.

The most likely motive appears to be financial.

The malware looked for cryptocurrencies, passwords, sessions, cloud credentials, tokens for development platforms and SSH keys. All immediately monetizable data: it can be sold, used to steal funds, exploited to compromise companies or employed in further supply chain attacks.

The ability to move over SSH also suggests that the goal was not just the individual Arch user, but the entire professional network reachable from their computer. Put differently: they were not attacking people, they were attacking the companies those people work for.

The technical elements point to at least one operator with solid Linux and supply chain skills: the malware uses Rust, modern cryptography, techniques to notice it is being analyzed, sandbox detection, systemd services, cron, Tor and SSH propagation.

It is possible that behind the July wave are the same operators of June's Atomic Arch campaign, or a linked group. The target, the attack model and the interest in credentials and development infrastructure are similar.

But there are also significant differences: the first campaign relied mainly on npm or Bun dependencies and included features tied to eBPF, while the new wave distributed ELF binaries directly and used a two stage Tor chain. It could be the evolution of the same malware or a copycat group that reused a method already proven effective. The public evidence does not allow a confident choice between the two hypotheses, and anyone who claims otherwise without reservation is guessing.

There is not enough to speak of a state operation. The scale of the credential and cryptocurrency theft is more consistent with financially motivated cybercrime, but even this remains an inference and not an attribution.

The real vulnerability was not in the code

Let us go back to the opening question: how could it happen.

The uncomfortable answer is that nothing anomalous happened. The attacker did not have to discover a sophisticated vulnerability in Arch Linux's servers. They used a legitimate process, the adoption of abandoned packages, exactly as it was designed. They inherited known names, existing histories and the trust accumulated by other developers. When that path was closed, they started publishing new packages.

No exploit, no flaw, no bug to fix with a patch. Which raises the truly annoying question: what exactly should Arch Linux fix, given that the system worked as intended?

The incident shows how fragile a supply chain is when code runs locally and review is left almost entirely to users. Fragile not because it is badly written, but because it rests on an assumption nobody ever verifies: that whoever maintains a package today is the same person who maintained it yesterday.

The most unsettling detail is not the .onion server, the malware written in Rust or the Tor process disguised as dbus-daemon. Those are technical acrobatics, and technical acrobatics can be studied and recognized.

The most unsettling detail is that, from the victim's point of view, it all begins with a completely normal gesture:

yay -Syu

A simple update. The thing we all do, without reading, because updating is the right thing to do. And right after, the keys to get into everything else.