Nazi Songs, “I Am Gay” Emails and Nobody in Charge at BGP.Exchange

Last updated 13 September 2026 at 17:19 CEST.

The website is not back.

At 15:54 CEST, clean external browser sessions opened both bgp.exchange and www.bgp.exchange and received the defaced “Bitch Daniel” page. A separate web fetch returned the same title and content. A full-page screenshot was preserved.

At 16:59 CEST, a fresh check still returned the defacement from the root domain, while lg.bgp.exchange redirected to it.

The continuing defacement is the public face of an incident that has already involved BGP.Exchange’s mailing platform, authenticated access to its own mail servers, an active Microsoft 365 tenant under its domain, its website and its domain registration.

A screenshot of a Discord statement attributed to the BGP.Exchange team has now been posted to Reddit. It says the domain was transferred without authorisation through an API, acknowledges that mail servers, Docker hosts and the web server were affected, and says route servers were not compromised. The screenshot’s authorship cannot be independently authenticated from the image, and it supplies no logs, indicators or recovery evidence. No incident explanation has been emailed to members, and there is still no independently hosted incident page or recovery timeline.

The correct status is therefore actively defaced, with recovery unverified.

It started with a legitimate sponsorship email

On 6 September, BGP.Exchange sent what appeared to be an ordinary sponsorship request. It asked for servers, networking equipment, connectivity, services or financial support. The message reached me, was signed by Daniel Watson and was delivered through the campaign platform used by the service.

Six days later, a new message arrived through the same channel. Its subject was “I am Gay,” and its body contained sexualised and Chinese-language harassment. The incident then escalated quickly.

Between 6 and 13 September, I received eight unique messages and preserved their complete headers. One is the legitimate baseline message; seven form part of the incident. Their headers document more than unwanted email: they show authorised use of several parts of BGP.Exchange’s email environment.

At the same time, the website was defaced and the official domain was transferred between registrars.

Timeline

Times are CEST unless marked UTC.

The last email initially resembles a genuine emergency appeal. It claims that the service is under attack and asks for money, hardware, server capacity and network resources. But its structure and language reuse material from the legitimate 6 September sponsorship email while changing the person named as sender.

The most direct inference is that whoever controlled the later campaign could access more than a random list of addresses. They could also view or reuse earlier campaign content and recipient information.

What the defacement and emails actually say

The content is not a coherent political manifesto. It deliberately combines incompatible symbols and causes: Chinese nationalism, criticism of the Chinese Communist Party, Taiwanese sovereignty, Hong Kong protest music, praise of Kim Jong-un, Nazi material and a message supporting transgender dignity. That contradiction is important. It looks more like shock trolling, personal humiliation and grievance-driven vandalism than evidence of one consistent ideology or of the attacker’s nationality.

The messages form the same kind of collage:

The page currently served at bgp.exchange presents six labelled music or score panels: North Korea, the Republic of China/Taiwan, the People’s Republic of China, Nazi Germany, “MTF” and “Black Hong Kong.” Its slogans range from praise of Kim Jong-un to “Republic of China is an independent country,” an anti-authoritarian PRC slogan, a Nazi salute, transgender equality and the Hong Kong protest slogan “Liberate Hong Kong, revolution of our times.” The displayed 2:1 and 3:2 scores are not explained.

Four audio players were present when the page was inspected:

1. The North Korea panel plays Manbo — Want to Eat Cantonese Food, an AI-voiced Chinese meme adaptation of the song If You Come for Three Winters. A misheard lyric about coming from Dandong and wanting Cantonese food caused versions of the song to become associated with Kim Jong-un online. The title and description match the cited meme upload, which labels itself as AI-generated.
2. The Republic of China panel plays the Republic of China/Taiwan flag anthem from Taiwan’s presidential-office website.
3. The People’s Republic of China panel plays the same Taiwanese flag anthem, making that placement an obvious political taunt rather than a PRC patriotic selection.
4. The Black Hong Kong panel plays the full original version of Glory to Hong Kong, linked to the creators’ site and their Internet Archive audio.

The Nazi Germany and MTF panels had images and slogans but no separate playable audio controls at the time of inspection.

The only structured set of demands is the bilingual letter at the bottom of the page. It demands that BGP.Exchange:

1. apologise for alleged racial discrimination;
2. admit that it is a VIXP;
3. admit to improperly collecting money;
4. admit to wasting hardware resources;
5. admit to abusing services;
6. admit to breaking local laws; and
7. accept a crude insult about the target’s mother.

It requires a reply containing an apology and explicit admissions, and warns vaguely of “further action.” No supporting evidence for the allegations is presented on the page. In this context, VIXP means a virtual Internet exchange: an exchange whose primary access is through GRE or similar tunnels rather than a physical Ethernet fabric. BGP.tools describes the distinction as a classification issue, not misconduct by itself. Because BGP.Exchange openly promotes GRE, VXLAN and ZeroTier connectivity, that demand appears to be part of a dispute about how the project represents itself and uses donated infrastructure.

The defensible reading is therefore not “the attacker is a Nazi” or “the attacker is Chinese.” The material is a bundle of mutually contradictory political triggers, obscene harassment, impersonation and a coercive ultimatum demanding forced admissions. The cryptocurrency appeal and the request for equipment and services add a financial or resource-acquisition element, but the page does not state a ransom or promise to restore the domain in exchange for compliance.

Does the LGBTQ and furry material identify the attacker?

One clue genuinely deserves attention: the Microsoft 365 DKIM records created around the takeover expose the attacker-associated tenant prefix furriesfun. The defacement also contains a transgender-equality panel, while malicious messages used subjects including “I am Gay,” “I am Daniel, I am gay” and “I am Daniel, I am MTF.” It is reasonable to ask whether the intruder was signalling an identity or group affiliation.

The evidence does not currently support that conclusion. Most of the identity-themed subjects explicitly assign the label to Daniel, the target of the defacement, rather than to the sender. The body of “I am Gay” is not an original declaration: it reproduces the 2023 Bum Bag song Hey Grandma I’m Gay, which predates this incident by three years. In context, the messages can be read at least as plausibly as sexualised humiliation and shock trolling. The live page is unsigned, and inspection of its HTML, JavaScript, styles and linked assets found no group name, handle, contact channel or hidden reference to SiegedSec or NullBulge.

SiegedSec is the obvious comparison because it publicly described itself as “gay furry hackers.” Its known operations were also conspicuously branded: researchers documented slogans such as “uwu gay furries pwn you,” named social accounts and public claims, while reporting describes the group claiming attacks on Telegram and publishing stolen data. Contemporary reporting also described it as non-financial and not seeking payment from victims. By contrast, the BGP.Exchange incident has no SiegedSec name or slogan, no located public claim or data dump, and it includes both a cryptocurrency appeal and a request for equipment and infrastructure. The Record documented SiegedSec’s public claims, data leaks and lack of a financial motive; The Register reported that the group said it disbanded in July 2024. A claimed disbandment is not proof that every member stopped operating, but the behavioural mismatch and absence of a claim make attribution unjustified.

NullBulge is an even weaker comparison. Early reporting presented the Disney intruder as a furry hacktivist group, but the US Department of Justice later said Ryan Mitchell Kramer admitted pretending to represent a fake Russia-based group called NullBulge. That episode shows why an online persona should not be treated as verified identity.

The defensible conclusion is narrow: the operator deliberately chose furry- and LGBTQ-themed material, and furriesfun may be a persona clue, an inside joke, a reference to the “gay furry hacker” trope or a false flag. It is not presently an attribution marker. Naming SiegedSec, NullBulge or any other group would require corroboration such as an authenticated public claim, reused infrastructure or wallet, a known alias, distinctive tooling, or forensic overlap. None has been identified in the public evidence reviewed as of this update.

Who is Daniel Watson?

The legitimate 6 September sponsorship email was signed by Daniel Watson. This is not an identity inferred from the attacker’s page. BGP.Exchange’s archived team page from June 2026 names Daniel Watson as “Founder & Administrator” and says he is the “Founder & Owner of BGP.Exchange.” It says Watson and Dennis de Houx maintained the nodes and BGP route servers and handled day-to-day operations. APNIC’s public registry independently names Watson in person object DW1481-AP and describes him as “BGP.Exchange ~ Owner / Administrator”; the same registry record identifies de Houx as an administrator and developer.

The surname was therefore publicly discoverable, and it would be inaccurate to say that nobody knew who operated the project. The stronger governance criticism is different: ordinary users should not have to reconstruct the accountable operator from an archived team biography, APNIC objects and Australian corporate records. The archived privacy policy defines the company only as “BGP.Exchange,” gives Australia as its country and says the service collected first and last names, email addresses, ASNs and usage data. It does not identify an incorporated legal entity, ABN or ACN, registered address, or responsible data controller. The archived terms of service likewise do not identify one.

Public network data also connect BGP.Exchange to Infininet Global Pty Ltd. APNIC lists daniel@infininet.com.au as the organisation contact for Infininet Global, while BGP.Exchange’s AS24381 is observed directly connected to Infininet’s AS24322. Most significantly for this incident, the old mail.bgp.exchange address preserved in the email headers was 103.248.51.133. The encompassing 103.248.51.0/24 is announced by AS24322, and public allocation data identify 103.248.51.128–191 specifically as BGP.Exchange production infrastructure inside that Infininet-announced block. This directly links the former mail infrastructure to the Infininet network, but it does not by itself prove that Infininet was the legal operator of BGP.Exchange or that Watson owned shares in the company.

The current ASIC company search for ACN 669 973 684 lists INFININET GLOBAL PTY LTD as registered on 25 July 2023 and deregistered on 10 May 2026. The official ABN history separately shows its ABN cancelled on 20 May and GST registration cancelled on 21 May. ASIC explains that, normally, a deregistered company ceases to exist as a legal entity and can no longer act in its own right. Infininet therefore cannot simply be assumed to be BGP.Exchange’s current operating company after 10 May.

BGP.Exchange also predates that company: its domain was registered in April 2021 and the earliest public PeeringDB participant records date from 6 May 2021, while Infininet Global Pty Ltd was registered in 2023. The company may have been a later infrastructure or operating vehicle, but the public-facing policies never say so. A current or historical ASIC company extract could identify former directors and shareholders; the free register does not. Until such an extract or first-party documentation is produced, it is defensible to say Watson publicly claimed ownership of the project, not that he has been proved to own Infininet Global Pty Ltd.

I found no reliable public source substantiating the page’s accusations that Watson or BGP.Exchange engaged in racial discrimination, improper fundraising, service abuse or violations of law. I also found no social-media profile that could be attributed to this Daniel Watson with sufficient confidence. The public record supports his founder/owner claim, operational role and the Infininet infrastructure link; it does not explain the attacker’s personal hostility or validate the demands.

This was not simple From-address spoofing

A visible From field proves very little. Anyone can type support@bgp.exchange into a mail client. The complete headers are what matter.

They show three distinct delivery phases:

This does not tell us how access was obtained. The cause could be stolen passwords, hijacked sessions, a compromised administrator, exposed API credentials or another entry point. It does rule out the easy explanation that an outsider merely forged the visible sender field without access to BGP.Exchange-controlled systems.

One authenticated SMTP session originated from an address announced by Cloudflare. That does not locate the operator. Cloudflare addresses may represent VPN, WARP, proxy or other distributed traffic and are not a sound basis for geographic or political attribution.

The domain really was transferred

In a public Reddit discussion, a person presenting themselves as a BGP.Exchange team member said the website had been hacked and the domain transferred away without consent. I have not independently verified the identity behind that account, but a central part of the timeline can be checked.

The official RDAP record for bgp.exchange records an inter-registrar transfer at 04:05 UTC on 13 September and another change minutes later. The registry data proves that a transfer occurred. It does not, by itself, prove that the transfer was unauthorised.

The domain was not near expiry — and the last pre-incident snapshot was not transfer-locked

The registry currently lists an expiration date of 1 April 2028 and the statuses client transfer prohibited, client update prohibited and transfer period. Those lock statuses were observed after the registrar transfer. They cannot be used as evidence that the domain was locked immediately before it moved.

The latest freely accessible pre-incident WHOIS snapshot I found is Whoxy’s record from 20 June 2026. It shows the old clara/khalid nameservers and reports the status as ACTIVE, with no clientTransferProhibited status. Earlier snapshots from 2022 and 2025 likewise show OK. This is evidence that the domain was not transfer-locked on 20 June, not proof of its precise status in the hours before 13 September. A lock could have been enabled or disabled during the intervening 85 days.

This was not an expiry or drop-catching event. ICANN’s Transfer Policy says a completed holder-authorised inter-registrar transfer extends the existing registration by one year. The current 2028 expiration therefore indicates a likely pre-transfer expiry of 1 April 2027 — about 200 days after the incident. The domain was nowhere near deletion for non-renewal.

An unlocked domain is not freely transferable. ICANN requires the registry to validate the domain’s unique AuthInfo/EPP code, and the gaining registrar must obtain the required authorisation. The evidence therefore points to compromise or abuse of domain-transfer authority: possibilities include the registrar or reseller account, the AuthInfo code, the registrant’s approval email or phone, an authenticated session, or a registrar support process. Public records do not identify which one failed.

If audit logs later show that clientTransferProhibited was active immediately before the request, then someone also had to remove that lock through the losing registrar or its process. That would be stronger evidence of registrar-account or registrar-side compromise. The public history available today does not establish that additional fact.

The claimed API explanation is technically plausible

The Discord statement says the transfer was made through an API interface. Its use of “Registry” and “registrar” is imprecise, and the public RDAP record does not reveal how the transfer was initiated. But the explanation fits a technically plausible path through the evidence.

The historical trail points strongly to Synergy Wholesale as the losing registrar stack. WhoisFreaks’ WHOIS history identifies Synergy Wholesale, IANA registrar ID 1609, in the original 2021 registration record. The June 2026 WHOIS snapshot uses the privacy address bgpexchange@obscure.me; Synergy’s own privacy terms state that its service creates addresses in precisely the @obscure.me format.

Synergy’s official API documentation shows that its wholesale platform supports programmatic domain management. The API’s domainInfo response can include the domain password/AuthInfo/EPP code, while the live API exposes unlockDomain, updateDomainPassword and updateNameServers operations. Synergy says API access requires a reseller ID, API key and an allowed source IP address.

If a compromised Docker or web host held those credentials and was on the API allowlist, an intruder could plausibly retrieve the EPP code, remove a transfer lock and change nameservers before transferring the domain to Tucows. That would reconcile the team’s API claim with the transfer and infrastructure access already documented. It remains a reconstruction, not a finding: the necessary API, authentication and registrar audit logs have not been published.

The incident is also documented by affected users in the r/networking thread “Weird Mail from BGP.Exchange” and covered by Born’s Tech and Windows World. Borncity reports that a reader could no longer sign in to the portal, that their VPN tunnels had stopped working and that peering appeared disrupted on 12 September. Those are relevant operator observations, but they remain a single attributed report rather than proof that the platform as a whole—or the global routing plane—was compromised. These public sources are evidence that other recipients and users experienced the incident, not proof of the initial-access method or total impact.

The DNS trail leads to a Microsoft tenant called furriesfun

The domain’s current DNS configuration provides direct evidence that whoever controlled the zone configured BGP.Exchange for Microsoft 365:

Microsoft’s DKIM documentation states that the component before the dynamic partition marker in this CNAME format is the organisation’s initial onmicrosoft.com domain prefix. In this case that prefix is unambiguously furriesfun. Both delegated selectors currently resolve to live Microsoft-hosted DKIM public keys.

This was not an incomplete setup. The first malicious Microsoft 365 message in the preserved material was created at 09:28 UTC on 13 September, signed as bgp.exchange with selector1, and recorded by Microsoft as passing SPF, DKIM and DMARC. The domain transfer was recorded at 04:05 UTC—five hours and 23 minutes earlier. That gives us a firm upper bound: the Microsoft tenant was able to send authenticated mail for BGP.Exchange by 09:28 UTC.

Historical data show that the configuration changed, but the free sources do not reveal the exact minute. WhoisFreaks’ nameserver history observed the old authoritative pair—clara.ns.cloudflare.com and khalid.ns.cloudflare.com—from 18 February 2023 through 8 September 2026. Its MX history observed the previous self-hosted cluster—mx05, mx10, mx15 and mx20.bgp.exchange—from 10 July through 8 September 2026. The current public DNS on 13 September instead delegates to anahi/david and routes mail to Microsoft 365. This bounds both changes to the interval between the last passive observation on 8 September and the current lookup on 13 September; it does not establish the precise change time.

Older snapshots support the same continuity. The WhoisFreaks SPF history shows the earlier non-Microsoft policy, while a July 2025 snapshot records the origin address 172.96.141.76. An independently indexed DNS propagation snapshot also shows the old clara/khalid nameserver pair. Separately, the earliest result in the public URLScan search for bgp.exchange captured the defaced page with the title “Bitch Daniel” at 14:07:59 UTC on 12 September. That is an observation time, not necessarily the moment the defacement began.

The URLScan observation predates the registry’s inter-registrar transfer event by almost 14 hours. The compromise was therefore externally visible before the transfer was recorded. This does not tell us whether the initial defacement used access to the old Cloudflare zone, access to the website origin, or a registrar-level DNS change made before the transfer completed.

A contemporaneous DNS lookup posted on 12 September showed _dmarc.bgp.exchange publishing v=DMARC1; p=none. That name returns no TXT answer now. At least one DNS record therefore changed between those observations.

The evidence is consistent with the domain being verified in, or moved to, a Microsoft 365 tenant controlled by the intruder and the DNS zone being edited around the takeover. The furriesfun tenant prefix and the authenticated malicious mail make that explanation highly likely. It is not yet possible to prove the exact creation time of the tenant or every DNS change without registrar, Cloudflare and Microsoft audit logs or a more complete passive-DNS archive.

Cloudflare itself is not proof of attacker camouflage. Historical snapshots confirm that BGP.Exchange already used Cloudflare, but the authoritative delegation changed from clara/khalid to anahi/david. This is more significant than editing an A or MX record. Cloudflare states that standard nameservers are assigned when a zone is created and cannot later be changed. It also explicitly allows the same domain to be added to another account: the additional zone receives its own nameserver pair and initially remains pending.

Only the pair delegated at the registrar is authoritative for ordinary public resolution. Under Cloudflare’s documented account-move process, the new zone becomes active after the registrar is updated; the old zone is marked “Moved Away.” Cloudflare’s zone-status documentation says a moved Free-plan zone is deleted after seven days, while a paid zone may also be deleted once the domain is active in another account. Old nameservers can continue answering direct queries for a period, but that does not make the old zone authoritative.

This changes an important inference. The new nameserver pair proves that a new Cloudflare zone was created and that the registrar delegation was changed. It does not prove that the intruder accessed or deleted the original Cloudflare zone, or possessed its API keys. Control of the registrar or transferred domain was sufficient to create a separate Cloudflare zone in another account and activate it. In the context of the recorded registrar transfer, defacement and newly active Microsoft tenant, an intruder-controlled replacement zone is the strongest explanation. Only registrar and Cloudflare audit logs can identify the accounts involved and the exact sequence.

What the claimed official statement does — and does not — establish

Read against the independent evidence, the statement is a mixture of corroborated facts and unverified assurances:

The statement is therefore broadly compatible with the observable incident, but it does not close the questions of data exposure, password storage, the initial entry point or total infrastructure scope.

No independently verifiable recovery channel

At the time of writing, the attacker’s page remains available through the official domain. Members have not received an incident notice explaining what happened, what systems were affected or how recovery will be authenticated. There is no separate status page that can be trusted independently of the affected domain and email environment.

Even when the original website eventually returns, familiar content will not by itself prove that control has been restored. If the underlying registrar account, DNS zone, deployment credential or origin remains controlled by an unauthorised party, the original page can be restored while access persists.

Before calling the service recovered, members should expect a statement delivered through a channel whose control can be verified independently of the affected domain and email environment. That statement should, at minimum, address:

• who currently controls the registrar and authoritative DNS;
• whether all administrative, mail, API and deployment credentials have been rotated;
• whether active sessions and access tokens have been revoked;
• how user passwords were stored and whether a forced reset is required;
• whether tunnel and route-server configurations were accessed or altered;
• the time window, known indicators and confirmed scope of the compromise.

The Discord statement offers broad assurances, but none of the audit evidence needed to verify them has been published at the time of writing.

The domain is not BGP

BGP.Exchange is not merely a website. It describes itself as a free, non-profit hybrid internet exchange with route servers and tunnel-based connectivity.

A PeeringDB export obtained on 13 September identifies AS24381 as a global, open, non-profit route-server network with a self-reported traffic level of 50–100 Gbps. It contains 50 public exchange entries: 45 BGP.Exchange-branded locations and five connections to external exchanges. Every branded location advertises a 10G connection. The public peering information was last updated on 11 September at 01:41 UTC, shortly before the incident became visible. These are self-reported PeeringDB profile data, not traffic measurements and not independent proof that every listed location or capacity was operational during the incident.

A deduplicated query of PeeringDB’s public netixlan records across all 51 exchange objects named BGP.Exchange gives a better estimate of the visible network footprint:

The largest locations in that pre-incident snapshot were Frankfurt with 232 distinct participant ASNs, Amsterdam with 197, Düsseldorf with 146, London with 125 and Zurich with 95. The Internet Society Pulse listing for BGP.Exchange London reports 130 connected autonomous systems, 113 of them using the route server. The small difference is consistent with different update times or counting methods.

This was a broad but predominantly long-tail community, not a hidden club of hyperscalers. Of the 509 external ASNs, 210 appeared at only one BGP.Exchange location, 297 at no more than two and only 32 at ten or more. PeeringDB’s own network classifications include 182 educational or research networks, 68 content networks, 53 access providers, 44 NSPs, 39 network-service providers, 30 non-profits and 25 enterprises; 68 had no type set. Many records are individual, hobby, research or small-provider networks.

I specifically checked the participant set for ASNs belonging to Cloudflare, Google, Microsoft, Amazon, Meta, Apple, Akamai, Netflix, Fastly, Hurricane Electric, Cogent, Arelion and NTT. None appeared in the BGP.Exchange participant snapshot. That does not mean those companies had no indirect relationship with the service—AS24381 itself connected to external exchanges where large networks are present—but there is no support here for claiming that the major hyperscalers were BGP.Exchange members.

The defensible public estimate is therefore about 510 networks in the service’s visible operational footprint, or 509 external participants if the related Infininet ASN is removed. It is not a count of registered user accounts, email recipients, concurrently active peer sessions or confirmed victims. That makes the incident serious. It also makes precise language essential.

A compromised website, transferred domain and abused email environment do not automatically prove that route servers or the BGP control plane were taken over. bgp.tools still shows AS24381 visible in the global routing system with originated prefixes, valid RPKI status and external relationships.

That is a snapshot, not an all-clear. Public BGP visibility cannot show whether the customer portal, tunnels, individual sessions, configuration data or administrative systems are intact. Borncity’s reader report specifically describes failed portal access and non-working VPN tunnels, but I have not independently verified the scope or duration of that disruption.

Did the network go down?

Parts of the service demonstrably did. On 13 September, the main site remained defaced, lg.bgp.exchange redirected to the defaced root page and the application statistics endpoint returned the defacement instead of JSON. The public portal, looking glass and operator-provided observability were therefore unavailable. Borncity’s report adds one user account of failed portal login, stopped VPN tunnels and disrupted peering on 12 September.

The global routing evidence does not show AS24381 disappearing. I queried RIPE NCC’s historical BGP State endpoint, which reconstructs the routes seen by all RIPE RIS collectors at a requested time. The observations around the incident were:

The same nine immediately adjacent ASNs appeared across all five snapshots. This is strong evidence against a total withdrawal or global outage of AS24381’s own announced prefixes during that window. It is not proof that BGP.Exchange’s internal route-server sessions, tunnels or layer-2 forwarding continued normally.

I then ran a direct event-level check against AS24381. RIPE BGPlay returned 26,118 observed announcement updates and zero withdrawal events for the 13 visible prefixes between 11 September 00:00 and the latest available data at 13 September 08:00 UTC. The high update count represents path observations across collectors, not traffic volume. The absence of withdrawals is the important part: RIPE’s collectors did not see AS24381 remove those prefixes from the global table during the incident window.

The latest RIPE routing-status result showed one IPv4 /24, twelve IPv6 /48s and nine observed neighbouring ASNs. The IPv4 route was visible to 322 of 324 relevant full-feed RIS peers and the IPv6 routes to all 318. A separate Hurricane Electric BGP view also listed the same 13 originated prefixes, all with valid RPKI origin status, and ten observed BGP peers. bgp.tools independently listed nine upstream relationships and 19 peer relationships. These services use different collectors and classification rules, so their neighbour totals are not expected to match exactly.

That limitation is structural. AMS-IX explains that an IXP route server exchanges routing information but does not participate in the forwarding path or carry member traffic. AS24381’s global visibility therefore cannot measure how many of BGP.Exchange’s roughly 510 participants had a working route-server session or how much traffic they exchanged with one another. The 50–100 Gbps value in PeeringDB is a self-selected profile band, not a live traffic graph.

There is one positive post-incident signal outside the BGP.Exchange platform: during a check at 16:55 CEST on 13 September, bgp.tools’ KleyReX page marked BGP.Exchange’s AS24381 external port as last seen online two hours earlier. That shows some external network presence survived after the compromise. It does not establish that the BGP session to KleyReX’s route server was up or that BGP.Exchange’s own member fabric was healthy.

The bgp.tools Frankfurt page exposes route-server, ping and MAC data feeds, but its current display did not provide a trustworthy before-and-after session count. An archived June snapshot also lacked the live route-server and last-seen markers needed for comparison. Zero visible status markers now therefore cannot responsibly be converted into “all peers are down.”

The precise conclusion is:

BGP.Exchange’s domain, website, portal-facing observability and multiple domain-authenticated email channels are documented as compromised or unavailable. At least one participant reported tunnel and peering disruption. Public collectors show that AS24381 did not vanish globally, but there is not enough independent telemetry to claim that the route servers, tunnels or participant traffic continued normally.

The cryptocurrency address

The 13 September email told recipients to send funds to 0x38e51E286318097D1DDC369CfF86c5b10629cb6f.

When checked on Etherscan at 15:48 CEST, the address had no Ethereum transactions and no ETH balance. The email did not identify a chain. This is therefore a time-specific Ethereum snapshot, not proof that the address has never been used on any EVM-compatible network.

There is no reason to send money or equipment in response to a message distributed from an environment that is demonstrably compromised.

What the messages reveal about recipient data

The genuine campaign and the first abusive campaign were both personalised with an organisation name and sent through the same SMTP2GO campaign system. They also used recipient-specific bounce and unsubscribe handling. The later “urgent support” message reused wording and structure from the legitimate sponsorship request.

That proves that the compromised campaign workflow could access or use recipient records, personalisation fields, campaign templates and delivery credentials. Other public reports say messages contained recipients’ full names, which would be consistent with access to additional contact fields.

The post-transfer messages make the continuity clearer. The registry recorded the transfer at 04:05 UTC on 13 September. At 09:28 and 09:45 UTC, two malicious Microsoft 365 messages were addressed directly to my existing member email address. At 11:01 UTC, the “urgent support” message named only the attacker-created sender in its visible To field but was still delivered to my address at envelope level, consistent with a blind-copy or distribution-list campaign.

The address can be followed across three different delivery environments:

This sequence matters. MX records tell other systems where to deliver incoming mail for a domain; they do not contain a customer or member mailing list. Compromise of DNS or the domain registration can let an intruder redirect mail and authenticate a new sending platform, but it does not reveal historical recipients. The use of my address through the old self-hosted mail system and then through the new Microsoft 365 environment shows that recipient data were retained, copied, exported or otherwise available independently of the MX change. Put simply: the address moved with the sender’s data, not with DNS.

Control of a domain allows an intruder to authenticate new senders; it does not reveal the addresses of existing members. The post-transfer delivery proves that the actor possessed my recipient address by 09:28 UTC on 13 September. In fact, the abusive SMTP2GO campaign and authenticated submissions through the old mail cluster show that it was already being used on 12 September. Those facts are not speculative. What remains unknown is where the address was obtained and how many other records were taken or reused. The strongest explanation is reuse or extraction of recipient data already available through the compromised SMTP2GO campaign, a mailbox, CRM, portal, logs or an export.

I am a registered BGP.Exchange user, although I do not actively use the network. The personalisation and the campaign footer are therefore consistent with a member-linked contact record. Together with the later delivery to the same address and other recipients’ reports of full names, the evidence supports a clear conclusion: an unauthorised actor possessed and used member-linked contact data.

That is a data exposure. It is not yet proof that the complete member database was downloaded or copied out of the environment. The address, organisation and other contact fields could already have been synchronised to SMTP2GO before the incident, allowing the actor to use the list without accessing the live portal database. Possible data sources include the campaign platform, a CRM, ticketing data, mailbox contacts or an export from the member portal.

Could the address instead have been collected from information visible to other members? A partial contact list could certainly be assembled from PeeringDB, RIR/WHOIS records and ordinary web searches. PeeringDB explains that network contacts may be public or restricted to authenticated PeeringDB users. Those are organisation contact records, however, not automatically the login addresses of BGP.Exchange accounts. The BGP.Exchange FAQ says registration required an ASN, prefixes, an email address and a password, but it does not say that the registration email was shared with other members. The PeeringDB export supplied for this investigation contains only BGP.Exchange’s own support address and no list of participant emails.

My address is also discoverable in public material elsewhere, so this single address alone cannot prove which database was the source. But the same organisation personalisation, recipient-specific campaign identifiers and continuity from BGP.Exchange’s established SMTP2GO workflow to its old mail servers and then Microsoft 365 fit reuse of BGP.Exchange-controlled contact data much better than an unrelated public-web scrape. Even if some addresses were independently public or visible to authenticated peers, their harvesting and repeated use through compromised BGP.Exchange channels would not make the incident benign; it would only change the possible source of some fields.

The wider evidence makes this more serious than an isolated mailing-list incident. Whoever sent the messages could use the SMTP2GO campaign environment, authenticated SMTP through BGP.Exchange’s own servers and Microsoft 365 identities under the domain. That combination is consistent with broad administrative compromise or several stolen credentials. It is not, without logs or a database export, proof that every portal account or member record was accessible.

A second Discord screenshot linked from the Reddit discussion shows a participant labelled Watti answering “encrypted i believe” when asked whether passwords were encrypted or hashed. The image does not authenticate the speaker, document the implementation or prove that the password database was accessed. It therefore cannot establish that passwords were recoverable or exfiltrated. If the description is accurate, however, reversible encryption would not be an acceptable substitute for a salted password hash and would increase the consequences of an application-and-key compromise.

Members should nevertheless treat credentials associated with the service as potentially exposed, especially when a password was reused elsewhere.

How many people or networks were affected?

There is no responsible way to publish one confirmed victim number yet. The available evidence describes different populations:

The 510-ASN figure is the best available measure of potential network reach. It must not be reported as “510 breached organisations.” One ASN can represent an individual experimenter, a small network, a company or a large provider, and PeeringDB presence does not prove that the network had an active account or tunnel when the incident occurred.

What members and network operators should do now

1. Do not sign in through links or forms on the affected domain until control is confirmed through an independent channel.
2. Do not send cryptocurrency, hardware or services in response to the emails currently circulating.
3. Change the password immediately anywhere else it was reused. Enable multi-factor authentication where available.
4. Preserve original messages with complete headers. Screenshots alone omit essential forensic evidence.
5. Review active tunnels, route-server sessions, import and export filters, alerts and recent configuration changes.
6. Verify your announcements, RPKI/ROA objects, IRR data and external route-collector observations.
7. Treat the website as untrusted until recovery is authenticated independently.

What we still do not know

• How the initial access occurred.
• Whether one or several people are responsible.
• Whether the email, website and domain access came from a single compromise.
• How much member or configuration data may have been viewed or extracted.
• Whether route-server or tunnel configurations were changed.
• How many route-server sessions or tunnels remained active, and how much member traffic was actually exchanged during the incident.
• Whether the legitimate operators currently control the registrar, DNS, origin and email environment.

It is tempting to fill those gaps using the language of the messages, IP geolocation or claims published on the defaced page. That would be poor incident analysis. Language is not identity, a Cloudflare address is not a physical location, and a compromised website is not a reliable witness.

What we can already prove is serious enough: within days, someone could communicate as BGP.Exchange through its campaign platform, authenticated mail submission and Microsoft 365, while the public website was defaced and the domain was transferred. The attacker’s page remains online, without a recovery notice or trusted status channel.

For infrastructure built on operational trust, that absence is not a communications footnote. It is part of the incident.

Corrections

This article will be updated when new information can be documented. Corrections will be marked with a timestamp and an explanation.

---

Sources

• Eight unique received emails with complete headers, dated 6–13 September 2026, preserved by the author.
• Screenshot of the live defaced page captured in a clean browser session at 15:54 CEST on 13 September 2026.
• PeeringDB JSON export obtained at 15:57 CEST on 13 September 2026; public peering data timestamped 11 September at 01:41 UTC.
• Archived BGP.Exchange team page naming Daniel Watson as founder and owner
• Archived BGP.Exchange privacy policy
• Archived BGP.Exchange terms of service
• ASIC company search for Infininet Global Pty Ltd, ACN 669 973 684
• ASIC: effects of company deregistration
• Australian Business Register: Infininet Global Pty Ltd history
• RDAP record for bgp.exchange
• Tucows/OpenSRS registrar RDAP record for bgp.exchange
• Whoxy: current and historical WHOIS records for bgp.exchange
• WhoisFreaks: WHOIS history for bgp.exchange
• ICANN Transfer Policy
• Discord statement attributed to BGP.Exchange, mirrored on Imgur
• Shazam: Hey Grandma I’m Gay by Bum Bag, released in 2023
• The Record: SiegedSec’s public claims, data leaks and reported non-financial motive
• The Register: SiegedSec’s self-description and July 2024 disbandment claim
• DarkOwl: documented SiegedSec slogans, branding and public channels
• US Department of Justice: the Disney intruder pretended to represent the fake group NullBulge
• Discord password-storage discussion linked from Reddit
• Synergy Wholesale: WHOIS privacy addresses use @obscure.me
• Synergy Wholesale: API authentication and source-IP allowlisting
• Synergy Wholesale API and WHMCS documentation
• BGP.Exchange
• PeeringDB: AS24381 / BGP.Exchange
• PeeringDB: authentication and contact-data visibility
• PeeringDB: managing and sharing contact information
• Microsoft: DKIM configuration and tenant-prefix format
• Cloudflare DNS FAQ: nameserver assignment and re-added zones
• Cloudflare: moving a domain between accounts
• Cloudflare: zone status, including Pending, Moved and Deleted
• WhoisFreaks: historical nameserver records for bgp.exchange
• WhoisFreaks: historical MX records for bgp.exchange
• WhoisFreaks: historical SPF records for bgp.exchange
• Historical DNS propagation snapshot
• URLScan search containing the defaced-page capture from 12 September at 14:07:59 UTC
• AS24381 at bgp.tools
• RIPE NCC: historical BGP State data and methodology
• RIPE BGP State queries for AS24381 at 11 Sep 12:00 UTC, 12 Sep 00:00, 12 Sep 12:00, 13 Sep 00:00 and 13 Sep 12:00
• RIPE BGPlay event data for AS24381, 11–13 September
• RIPE current routing-status data for AS24381
• Hurricane Electric BGP Toolkit: AS24381
• AMS-IX: route servers do not participate in the forwarding path
• bgp.tools: BGP.Exchange Frankfurt
• bgp.tools: BGP.Exchange’s external KleyReX port
• Archived June 2026 bgp.tools snapshot for BGP.Exchange Frankfurt
• Internet Society Pulse: BGP.Exchange London
• Reddit: Weird Mail from BGP.Exchange
• Born’s Tech and Windows World: BGP.Exchange Website Compromised
• Etherscan: cryptocurrency address included in the email