Per ongeluk honderdduizenden telefoongesprekken naar militaire bases geregistreerd

Datum: 30 juli 2026

DNS-hijacking is absurd. In het verleden heb ik al verschillende .gov- en .edu-domeinen overgenomen, maar die heb ik direct gemeld en daarna gelaten.

Dit geval is echter anders. Het gaat over hoe ik de domeinen van de telefoonnetwerkinfrastructuur (e164.arpa) van volledige territoria in handen kreeg en per ongeluk honderdduizenden telefoongesprekken naar militaire bases registreerde. Maar laten we bij het begin beginnen.

Wat is e164.arpa eigenlijk?

ENUM (e164.arpa) was een idee uit het begin van de jaren 2000 [1]: neem een telefoonnummer, draai de cijfers om, zet er punten tussen en voeg .e164.arpa toe aan het einde. Zo wordt +49 30 123456 iets als 6.5.4.3.2.1.0.3.9.4.e164.arpa.

Hieruit blijkt dat elk Duits nummer onder .9.4.e164.arpa valt, wat de zone is voor alle +49-nummers. Deze zone wordt beheerd door DENIC (dezelfde organisatie die .de beheert). Dit betekent dat DENIC bepaalt welke provider of persoon welke nummerreeksen binnen die zone krijgt, vergelijkbaar met hoe zij .de-domeinen uitgeven. Dit maakt het systeem gedecentraliseerd, waarbij elk land zelf beslist over de delegatie.

Het idee was dat providers deze domeinen konden opzoeken en een record terugkregen met de melding: "dit nummer is bereikbaar via SIP/VoIP op dit adres". Hiermee kon het dure telefoonnetwerk worden overgeslagen en konden gesprekken via het goedkope internet worden omgeleid.

Het systeem is echter nooit echt van de grond gekomen en werd zelfs in de beginjaren nauwelijks gebruikt. In de loop der jaren is het verder verslechterd en tegenwoordig is het in feite volledig dood. Ik bezit zelf overigens 5.8.7.1.7.1.3.2.6.1.9.4.e164.arpa en laat dit verwijzen naar deze website, hoewel dat technisch gezien niet is toegestaan (je kunt mijn tweede telefoonnummer eruit afleiden!). Duitsland is een van de laatste landen die technisch gezien nog steeds de registratie van een e164.arpa-domein toestaat; ik was de eerste persoon sinds 2019 die er een registreerde [2].

De RFC stelt dat je op deze domeinen alleen NAPTR-records moet instellen; dit zijn de records die providers vertellen waar een gesprek naartoe moet worden gerouteerd. Er staat expliciet dat .arpa-domeinen absoluut niet als normale "domeinen" gebruikt mogen worden om zaken als websites te hosten; ze zijn bedoeld als "infrastructuur"-domeinen (denk bijvoorbeeld aan in-addr.arpa voor reverse DNS-lookups).

Er is echter niemand die je daadwerkelijk kan tegenhouden. Uiteindelijk is het gewoon DNS, en niets verhindert je om er een A-record op te plaatsen en een website te hosten. Sommige mensen vinden dit erg vervelend en proberen Certificate Authorities te overtuigen om geen certificaten meer uit te geven voor .arpa-domeinen [3].

Het kapen van het telefoonnetwerk van een territorium

Uit nieuwsgierigheid naar hoe verwaarloosd dit hele systeem was, scande ik e164.arpa om te zien of er gedelegeerde zones waren die gekaapt konden worden.

Ik vond drie landcode-zones: 0.9.2.e164.arpa, 6.4.2.e164.arpa en 7.4.2.e164.arpa. Deze waren allemaal gedelegeerd aan dezelfde twee nameservers: ns6.icb.co.uk en ns.enum.org.uk.

Korte uitleg voor niet-DNS-experts: wanneer een domein is gedelegeerd aan een nameserver, betekent dit in feite: "voor elke vraag over dit domein, ga naar deze server, die heeft de antwoorden". Als ik de nameserver controleer waarnaar een domein verwijst, controleer ik elk DNS-antwoord voor dat domein.

icb.co.uk bestaat nog als domein, maar het specifieke subdomein ns6.icb.co.uk resolveert nergens meer naar. Dit betekent dat elk verzoek terugvalt op de tweede nameserver in de lijst: ns.enum.org.uk.

Dat domein was verlopen, dus ik kocht het voor slechts 5 euro. Zo controleerde ik plotseling de DNS voor 0.9.2.e164.arpa, 6.4.2.e164.arpa en 7.4.2.e164.arpa. Omgedraaid zijn dit de telefooncodes +290, +246 en +247: respectievelijk Saint Helena, het Brits Indisch Oceaangebied (Diego Garcia) en het Ascension-eiland (toevallig hebben deze territoria ook de populaire ccTLD's .sh, .io en .ac).

Om duidelijk te maken wat dit betekende: wanneer een provider een ENUM-lookup doet voor een van deze nummers, vragen ze in feite: "waar moet ik dit gesprek naartoe routeren?". Ik kon antwoorden met wat ik maar wilde. Ik had het kunnen richten naar mijn eigen SIP-server, het inkomende gesprek accepteren en vervolgens een uitgaand gesprek plaatsen naar de werkelijke bestemming met een gespoofd nummer.

De persoon die gebeld werd, zou zien dat het originele nummer belde en zou na het opnemen spreken met de persoon aan de andere kant alsof alles normaal was, terwijl ik onzichtbaar in het midden van het hele gesprek zou zitten. Theoretisch zou ik dit kunnen doen voor elk verzoek dat ik kreeg, mits er nog iemand dit systeem gebruikte.

Ik heb dit direct gemeld via meerdere kanalen bij de Britse overheid, maar kreeg geen reactie. Mijn vermoeden is dat iemand bij het Internet Computer Bureau (die ze vroeger blijkbaar beheerde) deze nameservers meer dan tien jaar geleden heeft ingesteld. Daarna is e164.arpa langzaam uitgestorven, en wie het ook had ingesteld, is ermee gestopt of is het simpelweg vergeten. Hierdoor bleef er niemand over om een domein te vernieuwen waar niemand meer wist dat ze afhankelijk van waren.

Controleren of er daadwerkelijk gebruik van wordt gemaakt

Q Misell (een onderzoeker van het Max-Planck-Institute for Informatics) hoorde hiervan en meldde het namens mij bij RIPE (die e164.arpa beheert), maar RIPE weigerde ook actie te ondernemen. Dit kwam omdat e164.arpa-delegaties worden beheerd door een ITU-T-comité op VN-niveau. RIPE was niet bereid om in te gaan tegen een besluit van een VN-comité, wat waarschijnlijk een bureaucratische nachtmerrie zou zijn.

Q vroeg me ook of ik data had over hoeveel verkeer deze zones daadwerkelijk kregen, wat ik niet wist. Omdat ik daar zelf erg nieuwsgierig naar was, stelde ik logging in op 0.9.2.e164.arpa (Saint Helena) en wachtte een volle dag.

Er kwam geen enkele query binnen. Nadat ik mijn best had gedaan om iemand alert te maken zonder succes, hield ik de domeinen gewoon, aangezien niemand er blijkbaar op vertrouwde. Ik hostte mijn persoonlijke site erop, startte een Fediverse-instantie en een Matrix-homeserver, en gaf subdomeinen aan vrienden. Het leek me een onschadelijk en speels experiment met een dood systeem.

Zes maanden later...

Uit nieuwsgierigheid controleerde ik na zes maanden de logs van alle drie de zones, aangezien ik logging op de andere twee ook had ingeschakeld bij de installatie.

Ik vond honderdduizenden ENUM-queries, allemaal gelogd [4]. Omdat de domeinnaam letterlijk het telefoonnummer in omgekeerde volgorde is, kun je dit simpelweg terugdraaien om het echte nummer te krijgen. Ik had dus volledige telefoonnummers, tijdstempels en de bron-IP-adressen van de DNS-resolvers die de verzoeken deden.

Bijna geen van het verkeer was voor Saint Helena (0.9.2.e164.arpa); het kwam bijna volledig uit 6.4.2.e164.arpa en 7.4.2.e164.arpa: Diego Garcia en het Ascension-eiland. De bron-IP's waren voornamelijk Amerikaans. Dat verklaart waarom ik oorspronkelijk geen verkeer zag, omdat ik toen alleen Saint Helena logde.

Ik had dus per ongeluk honderdduizenden telefoonnummers en tijdstempels geregistreerd van gesprekken naar militaire bases. Zoals eerder beschreven, had een kwaadwillende actor elk van deze gesprekken simpelweg via een Man-in-the-Middle (MITM) aanval kunnen onderscheppen. Hoewel ik geen expert ben, ga ik ervan uit dat in honderdduizenden gesprekken tussen soldaten en hun families onvermijdelijk gevoelige informatie zou weglekken. Een natiestaat met interesse in wat er op die bases gebeurt, zou het fantastisch hebben gevonden om maandenlang onopgemerkt op deze informatie te zitten.

Het is niet moeilijk voor te stellen wie specifiek geïnteresseerd zou zijn in inlichtingen over Diego Garcia, maar daar kom ik later op terug.

Mijn DNS-server antwoordde met een NXDOMAIN voor alle queries, waardoor het verkeer gewoon via het normale telefoonnetwerk werd gerouteerd. Maar na deze realisatie heb ik de DNS-server uitgeschakeld en alle logbestanden verwijderd.

Plotseling is er aandacht

Ik meldde het voor de tweede keer bij het National Cyber Security Centre (NCSC) van het VK. Deze keer, toen ik vermeldde dat er militaire bases bij betrokken waren, toonden ze plotseling veel interesse.

Ze konden niet achterhalen wie de verlopen delegatie oorspronkelijk had ingesteld, en het correct oplossen ervan liep tegen dezelfde problemen met het ITU-comité aan als eerder. Hierdoor veranderde er een tijdlang niets. Zelfs een jaar later was ik nog steeds eigenaar van het domein en had ik theoretisch het verkeer kunnen onderscheppen, hoewel ik de zone volledig had gewist zodat ns.enum.org.uk op dat moment voor alles NXDOMAIN teruggaf.

Vervolgens vuurde Iran op 20 maart 2026 ballistische raketten af op Diego Garcia [5]. Het was misschien interessant geweest om te zien of er die dag een piek was in gesprekken van bezorgde familieleden, maar tegen die tijd was ik allang gestopt met loggen. Dit incident onderstreept echter dat een staatactor geïnteresseerd zou kunnen zijn in deze informatie.

Kort daarna lieten ze me het eigendom van het domein direct aan hen overdragen, nadat ik het voor nogmaals 5 euro had moeten vernieuwen (anders zou het weer beschikbaar komen en zou iedereen kunnen doen wat ik hierboven beschreef).

Het NCSC controleert nu ns.enum.org.uk, maar de nameservers voor die drie zones wijzen daar nog steeds naar.

Uiteindelijk ben ik 10 euro kwijt aan domeinkosten en was er helaas geen bug bounty (al ben ik dankbaar dat er niemand mijn deur heeft ingetrapt). Maar bovenal is het een grappig verhaal :P

***

Voetnoten

[1] RFC 3761 - The E.164 to URI DDDS Application (ENUM) [2] DENIC publiceert jaarverslagen over hun ENUM-registraties. De laatste keer dat iemand een registratie deed was in 2019, totdat ik er in 2025 drie registreerde. [3] (Geen verdere details beschikbaar in tekst) [4] Op dit punt had een vriend van mij (86dd) een secundaire nameserver voor de zones ingesteld, zonder logging. Ik had 100.170 queries naar 6.4.2.e164.arpa, 99.902 queries naar 7.4.2.e164.arpa en 9.133 queries naar 0.9.2.e164.arpa gelogd. Dit is ongeveer de helft van de totale queries; wat betekent dat er in totaal circa 400.000 verzoeken waren. [5] Wikipedia: 2026 Iranian strike on Diego Garcia