Double Counter is an anti-abuse bot: Discord servers add it to catch alt accounts and ban evasion. To do that it keeps records on the people who join those servers. On 4 October somebody took them.

The entry point is the part worth reading twice.

A machine nobody turned off

The attacker did not go through Double Counter's current infrastructure. They went through an old OVH server from a previous hosting setup, which was still running a publicly reachable Metabase analytics instance.

Getting from that forgotten box to everything else was short work. The attacker forged an administrator session in Metabase, which gave access to stored credentials. Those included a cloud service-account key with administrator rights, an administrator's saved command-line session, and the Discord bot token.

Nothing here required a novel exploit against the live service. The live service was never the way in. A box that had been migrated away from, left running with an analytics tool exposed, held credentials to everything that replaced it.

This is the same shape as infrastructure that is forgotten rather than decommissioned — a DNS record pointing at something nobody owns any more is the version of this that gets written about most. The common factor is not the technology. It is that migrations are judged complete when the new thing works, not when the old thing is gone.

The timeline shows a response that did not arrive in time

Double Counter's own disclosure is unusually precise about the clock, and the sequence is uncomfortable:

  • 12:03 — the attacker gets in.
  • 13:39 — a first token invalidation. Something had been noticed.
  • 15:09 to 15:34 — the data is copied.
  • About 17:55 — access ends.

An hour and a half passed between the first defensive action and the exfiltration, and the exfiltration still happened. Rotating one credential while an attacker holds an administrator key and a live shell session is not containment; it closes one door in a building where they have the master key. The useful lesson is about scope: once a service-account key with admin rights is gone, individual token rotations buy nothing until that key is revoked.

What was taken

By Double Counter's own numbers, the copied data covers roughly:

  • 28 million Discord IDs and usernames.
  • 27 million IP address and location records — country, region, city, postal code and ISP.
  • About 25 million user-agent hashes.
  • About 1 million unique email addresses.

The last figure is contested, and not by an attacker. Have I Been Pwned lists roughly 275,000 unique addresses in the data that was actually published — around a quarter of Double Counter's estimate.

Both can be true: a company counting what an attacker could have taken and a researcher counting what appeared in public are measuring different things. But the gap is worth naming rather than averaging, because the two numbers answer two different questions, and only one of them has been verified against the data.

The stolen Discord bot token did not sit idle either. The attacker granted themselves administrator rights on the support server, reversed a staff ban, and sent invitations across roughly 50 large Discord servers. A stolen Stripe key produced 7,316 dollars in fraudulent charges on a company card.

The bot was the aggregation point

There is a structural point here that applies well beyond this one service.

The data was not Discord's to lose, and Discord has said so: it confirmed awareness, stated that this was not a breach of Discord, and disabled new installs of the app pending investigation. That is accurate.

It is also the problem. A third-party bot added to a server for moderation collects, by design, the identifying details of everyone who joins — and does it across thousands of communities at once. The individual user never agreed to anything with Double Counter, never heard of it, and in most cases could not have named the bots running in a server they joined. The aggregation happened at a layer nobody was looking at, and the security of it was whatever one small team's oldest server happened to be.

What to do

  • Inventory what you have migrated away from, not only what you run. The question is not what is in production; it is what is still powered on and routable.
  • Treat an analytics or BI tool as a credential store, because it is one. Metabase holds connection details for everything it reports on.
  • Write the containment order down before you need it: revoke the broadest credential first. Token rotation while an admin key is live is motion, not progress.
  • If you run a Discord community, look at which bots you have added and what each one retains. Permissions granted in a hurry years ago are still granted.

What is not established

  • Which Metabase flaw or technique was used to forge the administrator session.
  • Why the true email count differs from Double Counter's estimate by roughly a factor of four.
  • What was noticed at 13:39, and why the response stopped at a token rotation.
  • Whether the copied data beyond the published subset has been circulated.
  • Whether Discord will require anything of app developers as a result, beyond pausing installs of this one.