Two Arrested in Perth Over Hacks on More Than a Thousand Organisations

Australian police have arrested two people in Perth accused of belonging to TeamPCP, a prolific hacking group blamed for a series of high-profile breaches of large technology companies in recent months.

The two have been charged with more than a dozen hacking, money laundering and other cybercrime offences.

The method

According to a statement from the Australian Federal Police, the men are accused of widespread breaches involving the compromise and tampering of popular open source projects. The aim was to infect a large number of computers, steal credentials and data, and then extort victims into paying a ransom.

That is a supply chain attack, and it explains how a small group reaches an enormous number of targets. Rather than breaking into a thousand organisations individually, an attacker compromises a single widely used package and waits for those organisations to install it themselves as part of a routine update.

The FBI's cyber division chief Brett Leatherman was quoted as saying the two alleged members are accused of hacking into more than a thousand organisations.

Two men were arrested in Perth and charged with more than a dozen hacking, money laundering and cybercrime offences. Photograph: Australian Federal Police

Why open source is the vector

The modern software stack is assembled from thousands of freely available components, most maintained by small numbers of unpaid volunteers, and most installed automatically without inspection.

That model has produced extraordinary productivity and a structural weakness that has been understood for years: the trust relationship between a package and the applications that depend on it is almost entirely implicit. A maintainer account taken over, or a malicious contribution merged, propagates to everyone downstream at the speed of their build pipelines.

The defences that exist — signed releases, reproducible builds, dependency pinning, provenance attestation — are effective and unevenly adopted, because each one adds friction to a process whose appeal is that it has none.

The jurisdictional question

It is unclear whether the US Justice Department intends to seek extradition, and the FBI declined to comment.

That uncertainty is typical. Cybercrime prosecutions routinely involve suspects in one country, infrastructure in a second, and victims in dozens more, and the decision about where a case is tried turns on evidence-sharing arrangements and sentencing exposure as much as on where the offences occurred.

Why arrests still matter

There is a widespread assumption that attribution and arrest are effectively impossible in cybercrime, and the record broadly supports pessimism — most groups operate from jurisdictions that will not cooperate.

TeamPCP appears to be an exception, and the reason is mundane. Operating from a country with strong law enforcement relationships means the usual protection does not apply, however good the technical tradecraft. The group's alleged sophistication in compromising open source projects did not offset the vulnerability of being physically located in Perth.

The targets

TeamPCP has been linked to intrusions at companies including Mercor and OpenAI, which reflects a deliberate choice of victim rather than opportunism.

AI companies are attractive targets for the same reason they are valuable businesses: they hold large volumes of proprietary data, they have grown quickly enough that internal security often lags engineering, and they depend heavily on exactly the open source ecosystem this group is accused of poisoning.

What happens to the compromised packages

An arrest does not clean up the damage. Compromised versions of open source projects remain in caches, mirrors, lockfiles and container images long after the malicious release is pulled.

Organisations that installed an affected version during the exposure window have to identify it, rotate any credentials that machine could reach, and rebuild anything derived from it. Most will never know they were affected, because dependency chains run several layers deep and few organisations maintain a complete inventory of what their software is actually built from.