Targeted attack on Double Counter’s infrastructure
Published 5 October 2026 · All times UTC
Status: contained, service restored
The attacker’s last action in our cloud infrastructure was recorded at 17:54 on 4 October. A full audit found no backdoor left behind. Double Counter was restored at 19:19 with new credentials and is under continuous monitoring.
Summary
On 4 October 2026, Double Counter was the target of a deliberate, multi-stage attack. The attacker broke into a server from our previous hosting setup through a vulnerability in an analytics tool it was still running, then used credentials found on that server to reach our cloud infrastructure and adapted to each of our containment steps. During the attack they took control of the bot’s Discord token, used it to post links to their own Discord server in about 50 large servers, copied part of one of our databases, and used a stolen payment key to commit financial fraud on a separate account.
We cut off their access, found no persistence, replaced the exposed credentials and restored the service at 19:19. We sincerely apologise to everyone affected.
- 5 h 51 min of attacker activity in our cloud (12:03 → 17:54).
- About 12 GB copied from one of our databases (15:09 → 15:34).
- About 50 large servers where the bot posted the attacker’s links.
- $7,316 in fraudulent charges on a separate payment account. Customer funds are safe.
How the attack unfolded
- 1
Initial access
The entry point was an old server from our previous OVH hosting setup. It was no longer in use and no longer linked to the operational Double Counter service. The attacker probed it from rotating VPN addresses starting on 3 October at 04:37, then worked methodically through a list of usernames — root, nathan, debian, and service names such as analytics-sync and metabase — before logging in at 00:47 on 4 October; the login took only a few tries once they reached the right account. The way in was a self-hosted analytics tool (Metabase) that was still running, and publicly reachable, on that retired server: a vulnerability in it let the attacker forge an administrator session and, through it, reach the host and the credentials used to log in — rather than a password leaked from our source code, which contains none. The server held two credentials for our cloud: the key of a service account (a non-human identity our services use to talk to the cloud, here with administrator rights) and an administrator’s saved command-line session. The attacker created no new account; they used these two existing, legitimate credentials, which is part of why their activity initially blended in.
- 2
Entry into the cloud (12:03)
With the service-account key, the attacker added their own SSH key to the project (12:08) and exported one of our databases into a storage bucket they created (12:19–12:35). That export was never downloaded.
- 3
Control of the Discord bot (12:26)
They opened a shell inside a running bot container and read the bot token. On our support server they used it to give their account Administrator rights (13:24) and to unban it after our staff banned it (13:33), and from 13:30 they used it to post links to their own Discord server in about 50 large servers that use Double Counter.
- 4
Adapting to our response (14:46–15:34)
When we set a new bot token, they read it within two minutes. They then deleted backups they had created, changed the database administrator password to lock our services out (15:09), and started copying the databases they could find from a cloud-hosted machine until we located and terminated their session (15:34).
- 5
Fallback credential (15:54–17:54)
When we revoked the service-account key, they switched to the administrator session taken from the same server, re-added their SSH key and connected to the database again, without any measurable data transfer. All sessions of that account were revoked at about 17:55.
Timeline
Times marked ≈ are accurate to within a few minutes; all others come from system logs.
| Time | Type | Event |
|---|---|---|
| Friday 3 October | ||
| 04:37 | Attacker | First probing of the legacy server — including a publicly reachable analytics tool on it — and of an internal API, from rotating VPN addresses. |
| Saturday 4 October | ||
| 00:47 | Attacker | Login to the legacy OVH server through a vulnerability in an analytics tool running on it, after working through a list of usernames. |
| 12:03 | Attacker | First use of the service-account key in our cloud. |
| 12:08 | Attacker | SSH key added to the cloud project. |
| 12:19–12:35 | Attacker | Database export to a bucket they created. Never downloaded. |
| 12:26 | Attacker | Shell in a bot container. Bot token obtained. |
| 13:24–13:34 | Attacker | Support server: Administrator granted by the bot (13:24), about 15 roles (13:26), staff ban (13:32), bot unban (13:33), ban again (13:34). |
| 13:30 | Attacker | The bot begins posting links to the attacker’s server in large servers. |
| 13:39 | Response | We invalidate the bot token. The bot goes offline and the attacker loses control of it. |
| ≈14:45 | Response | New bot token installed; verifications resume by 14:49. |
| 14:46–14:51 | Attacker | New shells in containers. New token exposed. |
| 14:57 | Response | Real-time monitoring of every permission the bot grants goes live. |
| 15:04–15:09 | Attacker | Backups deleted, database administrator password changed. Verifications stop. |
| 15:09–15:34 | Attacker | Database tables copied (about 12 GB). |
| 15:17 | Response | Intrusion identified in the cloud audit logs. |
| 15:20 | Response | Service-account key disabled; database protected against deletion. |
| 15:21 | Response | Attacker’s SSH key removed from the project. |
| 15:24 | Response | Database closed to the internet. |
| 15:28 | Response | New database password set; verifications resume. |
| ≈15:34 | Response | Attacker’s database-copy session located and terminated. |
| 15:36 | Response | Stolen key deleted; its service account disabled and stripped of all rights. |
| 15:54–16:46 | Attacker | Fallback to the administrator session: container shells, database connection. |
| ≈16:08 | Response | Double Counter taken offline deliberately to cut off the fallback access. |
| ≈16:19 | Response | Bot token reset and moved to our secret store. |
| 16:25–16:52 | Response | Cache database migrated off the public internet onto a private network in our cloud. |
| 17:11–17:12 | Attacker | Using a stolen payment key, runs fraudulent charges on a separate (Atis) payment account. |
| 17:14 | Response | All payment-provider keys revoked and the affected account secured; the two customer charges are refunded. |
| 17:33–17:54 | Attacker | SSH key re-added, then five database connections. Last recorded action at 17:54:57. |
| ≈17:55 | Response | All sessions of the administrator account revoked. The attacker’s cloud access ends. |
| ≈18:00 | Response | Legacy OVH server shut down. |
| 18:00–18:40 | Response | Backdoor audit of 14 cloud projects: nothing found. Database password replaced again (18:15). |
| ≈18:35 | Attacker | Invitations posted in our support server through two webhooks. |
| ≈18:40 | Response | All ten exposed Discord webhooks deleted. |
| 19:11–19:12 | Response | Logging of every secret read enabled; alerting on sensitive cloud changes armed. |
| ≈19:14–19:16 | Response | All session-signing keys replaced; bot token reset a final time. |
| 19:19 | Response | Double Counter restored with new credentials. |
| 19:40 | Response | New Discord webhooks put into service, their addresses held only in our secret store. |
Personal data affected
The copy tool works through that database in a fixed order, so by comparing the ≈12 GB that left with the size of each table we can assess what was copied. The figures below cover personal data, including, for completeness, data held outside that database. Counts are approximate.
| Data | Records | Status |
|---|---|---|
| IP addresses, each linked to a Discord ID and username (accounts flagged as alts, and verified users) | ≈ 27 M | Partly copied |
| User agent hash: a one-way hash derived from the browser’s user agent, used for alt detection | ≈ 44 M | Copied |
| Email addresses: server administrator contacts (≈256k), dashboard accounts (≈220k), Doogle accounts (≈832k), advertisers and API customers (≈210) | ≈ 1.3 M | Copied |
| VPN detection logs (IP addresses and user agents) | ≈ 15 M | Not copied |
| Behavioural fingerprints: product events, device and browser characteristics, acquisition tracking | ≈ 25 M | Not copied, stored elsewhere |
| Cold storage: database of user data and IP addresses (≈ 58 M users, including only ≈ 800k email addresses), not used by the main verification process, in the same format as the affected database | ≈ 58 M | Not affected |
| Full export of the affected database, created at 12:35 | 5.0 GB | Not downloaded |
The IP-address records sit in two tables. The first (alt detection, ≈5.4 M) was copied in full. The second (verified users, ≈21.7 M) was being copied when we ended the session: from the volume transferred we estimate that about 20% had left, and because we cannot tell which rows, we treat the whole set as exposed.
Not affected: our cold storage, a separate database of user data and IP addresses for ≈ 58 M users (including only ≈ 800k email addresses). It is used by some of our other processes but not by the main verification process, is kept outside the infrastructure involved in this incident, and was not affected. Our behavioural data database was stored elsewhere and is confirmed to be unaffected and not accessed. Discord passwords, which Double Counter never receives, and stored payment card details, which are held by our payment provider, were not in the affected database either. The payment account that processes Double Counter and Doogle subscriptions shows no unauthorised charges; the payment fraud described below hit a separate account.
Payment fraud
Among the secrets the attacker could read in our cloud was the payment-provider (Stripe) key of a separate Tellter product, Atis. They used it to commit financial fraud on that account on 4 October, between 17:11 and 17:12:
- A series of escalating test charges ($1, $10, $100, $1,000) against one of our own company cards, totalling $7,316.
- Two small charges, $3 and $15, to two of that product’s customers. Both have been refunded in full.
Only three cards were charged in total — one of our own and two customers’ — and no other customers were affected. We revoked every payment-provider key at 17:14, rotated the credentials and secured the accounts. All customer funds are safe. No stored card numbers were exposed: the payment provider holds those, and the attacker acted through the account, not the card data.
Impact on Discord servers
- Links to the attacker’s server. The bot posted invitations to the attacker’s Discord server in about 50 large servers that use Double Counter, based on the reports we have received. These messages appeared as sent by Double Counter. The largest server targeted was “Steal a brainrot”. Substantially all of these messages have been deleted, by us or by each server’s moderation team. We are not linking to the attacker’s server here.
- Our support server. Administrator rights and about fifteen roles granted to the attacker’s account (Discord ID
931487207443804161), one unban, and invitations posted through two webhooks.
Messages sent with the stolen token went straight to Discord without passing through our systems, so we identified the affected servers from the reports we received and from the bot’s own message history.
What we have done
Cut off the attacker
- Disabled, then deleted, the stolen service-account key, and stripped its account of every right.
- Revoked all sessions of the administrator account whose saved login was on the server.
- Removed the attacker’s SSH key, shut down the legacy OVH server, and removed its access to our source code.
- Reset the bot token and deleted all ten Discord webhooks whose addresses could have been exposed.
Closed the ways in
- Closed the affected database to the internet: it now accepts only authenticated connections from our own services.
- Migrated the cache database off the third-party, internet-facing host it used onto a private network inside our own cloud, with no public address.
- Disabled the over-privileged service account. No long-lived service-account key remains in our cloud project.
Rotated our secrets
- Replaced the credentials the attacker could have read: the bot token, the database and cache passwords, every session-signing key (which signed everyone out), our payment-provider keys and webhook secrets, our Discord application secrets and our AI provider keys. The keys of our remaining third-party providers are being rotated.
- Signed every staff member out of our internal staff panel and started resetting staff credentials.
- The bot token and the Discord webhooks now live in a dedicated secret store, never in our code.
Verified and watched
- Audited 14 cloud projects for persistence: no key, account, permission, machine, scheduled job or container image was left behind by the attacker.
- Turned on logging of every read of our stored secrets, alerting on any sensitive change to our cloud, and real-time monitoring of the permissions the bot grants, with continuous monitoring since the service was restored.
What you should do
Server administrators
- Delete any message sent by Double Counter on 4 October between 12:00 and 16:30 UTC that invites people to another server.
- Check your audit log for actions by Double Counter in that window.
Members
- Nothing to change on your Discord account.
- Don’t join servers advertised in unexpected messages from Double Counter.
- If you verified between 13:39 and 14:49 UTC without getting your role, verify again.
Doogle, Atis, advertiser and API customers
- Doogle users, advertisers and API customers: your email address was exposed, so expect phishing attempts.
- Atis customers: no action is needed. The two charges made during the incident have been refunded and your funds are safe.
- We never ask for passwords, tokens or payment by email or private message.
Legal and notifications
- We notified the French data protection authority (CNIL) on 5 October 2026, under reference FR2610050000001.
- We have engaged legal counsel and are pursuing those responsible in both France and the United States. A criminal complaint is being filed, and our lawyers are building the case on platform and Discord logs, direct-message screenshots, and technical indicators collected from our own systems.
Contact
For questions or personal-data requests, write to [email protected], use the bot’s /privacy command, or reach us on our support server. We will update this page when the investigation concludes.
INC-2026-10-04 · Version 1.9 · Last updated 5 October 2026 · Tellter SAS, operator of Double Counter. This report reflects what we know at the time of writing and will be updated as the investigation progresses.