Ander domein achter een link: alarmsignaal of onschuldig?

Hang in je inbox vaak genoeg met de muis boven een link en je ziet het snel: het adres achter een link komt zelden precies overeen met de tekst. De mail van je bank noemt www.harbourline.example en de link gaat naar login.harbourline.example. Een nieuwsbrief noemt een webwinkel en linkt naar een mailingdienst. Een pakketbericht noemt een vervoerder en linkt naar iets heel anders. Een deel van die verschillen is dagelijkse kost; eentje is precies hoe phishing werkt. De kunst is weten naar welk stuk van de hostnaam je moet kijken.

Lees de hostnaam van rechts naar links

Zoek eerst het stuk tussen https:// en de eerste /, ? of # (of het einde van het adres als er geen volgt). Dat stuk kan meer bevatten dan de hostnaam: alles vóór een @ is niet de host, en een poortnummer aan het eind, zoals :8443, ook niet. In https://[email protected]/ is de host account-review.example.

Een hostnaam lees je van rechts naar links. In mail.harbourline.example is .example het topniveaudomein en harbourline.example het registreerbare domein: de naam die een persoon of bedrijf heeft geregistreerd en in handen heeft. Alles links daarvan (mail., www., login.) is een subdomein dat de eigenaar zelf aanmaakt of door een ander laat beheren. mail.harbourline.example en www.harbourline.example delen dus een registreerbaar domein, wat meestal, maar niet altijd, betekent dat dezelfde partij over beide gaat (over de uitzonderingen hieronder meer). Sommige landen gebruiken een achtervoegsel van twee delen: in www.phpfreelance.co.uk is het achtervoegsel .co.uk, dus het registreerbare domein is phpfreelance.co.uk.

Die linkerkant is ook precies waar oplichters zich verkleden. In harbourline.example.account-review.example is de bekende naam alleen maar een label op het domein van een ander: het registreerbare domein, helemaal rechts, is account-review.example. Een campagne tegen Booking.com uit 2025 gebruikte hetzelfde idee, met een Japans teken dat op een schuine streep lijkt. Zo stond het domein van de aanvaller, www-account-booking[.]com, verstopt achter tekst die las als een pad op booking.com. Ik heb dat voorbeeld uitgeplozen in het artikel over Reveal URLs.

Wanneer een ander domein een alarmsignaal is

Een verschil wordt een alarmsignaal als de link naar een ander registreerbaar domein gaat dan de tekst noemt, en die bestemming eruitziet als een imitatie. De bekende vormen:

• Een spelling die erop lijkt. harb0urline.example met een nul in plaats van de "o", een verdubbelde of verwisselde letter, of de merknaam met een geruststellend woordje erbij: harbourline-secure.example, harbourline-support.example. Een andere spelling bewijst geen andere eigenaar, maar niets in de naam laat zien dat de eigenaar van harbourline.example hem heeft geregistreerd, dus zie het als reden om beter te kijken.
• Het merk als versiering. harbourline.example.account-review.example: de merknaam staat er wel, maar alleen als subdomein op het registreerbare domein van een onbekende.
• Letters uit een ander alfabet. Geïnternationaliseerde domeinnamen mogen letters uit andere schriften bevatten, en sommige daarvan zijn niet van Latijnse letters te onderscheiden. Op 3 oktober 2026 liet Have I Been Squatted een nagemaakt apple.com zien waarvan alle vijf letters Cyrillisch waren, en dat Chrome 154 nog steeds in Unicode toonde, met een geldig certificaat. Webmail verschilde ook: in hun test met 20 geïnternationaliseerde afzenderdomeinen gold "Gmail decoded everything, and Outlook Web decoded nothing": Gmail Web toonde de afzenderdomeinen in Unicode, Outlook Web in hun xn---vorm. Die test ging over hoe het afzenderadres wordt weergegeven, niet over links of de phishingfilters van die diensten. In de .com-zone telden ze 733.509 geïnternationaliseerde domeinen en 161.894 lookalike-paren, met de kanttekening dat een lookalike-naam niet per se kwaadaardig is. Hun eigen 20 testdomeinen waren onderzoek, geen lopende campagne.
• Een zichtbaar adres dat ergens anders heen gaat. De tekst zelf luidt https://www.harbourline.example/account, maar de link gaat naar een domein dat er niets mee te maken heeft. Nieuwsbrieven doen dat soms om te tracken (zie hieronder). Een mailing- of trackingdienst die je herkent, verklaart waarom de hostnaam afwijkt, maar maakt de link nog niet veilig, zoals de gevallen van SendGrid en Trezor hieronder laten zien. Herken je de bestemming niet, behandel het dan als een mismatch.

Wanneer het meestal onschuldig is

Veel verschillen hebben een doodgewone verklaring. Als je die kent, zie je niet elke nieuwsbrief als een aanval, en weet je ook waar je toch even moet opletten.

• Subdomeinen van hetzelfde registreerbare domein. Tekst harbourline.example, bestemming mail.harbourline.example of login.harbourline.example: hetzelfde registreerbare domein, en dat is meestal onschuldig. Het bewijst alleen niet dat dezelfde partij de pagina beheert: een eigenaar kan een subdomein laten wijzen naar een dienst van een ander bedrijf, en blijft dat DNS-record staan nadat die dienst is opgeheven (een "dangling" DNS-record), dan kan iemand anders het subdomein overnemen. Microsoft beschrijft deze subdomain takeover en wijst erop dat het in phishingcampagnes wordt gebruikt.
• Klikregistratie in nieuwsbrieven. Mailingdiensten sturen elke klik vaak eerst via hun eigen trackingadres, dat je daarna doorstuurt naar de echte pagina. Een link met de tekst www.harbourline.example kan dus wijzen naar iets als click.mailer.example/…. Bij nieuwsbrieven is dat normaal, en zoals ik in het artikel over e-maillink-phishing schreef, zien tracking-URL's er verdacht uit, ook als ze onschuldig zijn. Het betekent wel dat de directe bestemming van de link niet de plek is waar je uitkomt, en dat ook een vertrouwd verzendplatform phishing kan bezorgen: in januari 2026 gebruikten aanvallers volgens meldingen gecompromitteerde klantaccounts bij SendGrid om die te versturen.
• Doorstuur- en herschrijfdiensten. Zoekmachines, klikregistratie voor advertenties en sommige zakelijke e-mailbeveiligingsdiensten (die links herschrijven zodat elke klik eerst langs hun scanner gaat) zetten allemaal hun eigen hostnaam vóór de echte.
• Verkorte URL's. Een link als short.example/a1B2 is op zich geen phishing, maar verbergt de bestemming volledig, dus er valt niets met de linktekst te vergelijken. Ga er voorzichtig mee om: gaat een bericht over geld, wachtwoorden of je account, klik dan niet, maar ga zelf naar de site.

Als elke tussenstap betrouwbaar lijkt

De lastigste gevallen zijn links waaraan helemaal niets afwijkends te zien is. Drie voorbeelden uit 2026:

• Een ketting van Google-adressen. Op 4 september 2026 beschreef het KnowBe4 Threat Lab een campagne die phishinglinks via Google-diensten leidde, zoals meet.google.com/linkredirect, google.com/url?q= en de klikregistratie van DoubleClick. De e-mailgateway zag zo "trusted Google domains at every hop", voordat de link bij de eigen infrastructuur van de aanvallers uitkwam.
• Een echte inlogpagina die je doorstuurt. Op 2 maart 2026 beschreef Microsoft misbruik van OAuth-redirects: links die beginnen op login.microsoftonline.com of accounts.google.com, met opzet zo gebouwd dat het inloggen mislukt, waarna de inlogdienst de browser doorstuurt naar een adres dat de aanvaller heeft geregistreerd.
• Een echte afzender. Op 9 september 2026 verstuurde een aanvaller die toegang had gekregen tot Brevo, het nieuwsbriefplatform van Trezor, een phishingmail vanuit het eigen account van Trezor. De link spoorde lezers aan een app te downloaden die om hun wallet-back-up vroeg (bericht van Trezor van 10 september 2026, bijgewerkt op 17 september).

De les: een vertrouwde eerste hostnaam, of een echte afzender, zegt niets over de uiteindelijke bestemming. Zit er in een vertrouwd adres nog een tweede adres verstopt, bijvoorbeeld na url=, q=, dest= of redirect_uri=, dan kan dat tweede adres een aanwijzing zijn voor waar je later heen wordt gestuurd. Waar de ketting eindigt, zie je er niet aan: de naam van de parameter bewijst niets over wat de dienst ermee doet, en het ingebedde adres kan gewoon de volgende tussenstap zijn, zoals in de ketting die KnowBe4 beschreef. Bij alles wat je vraagt in te loggen of te betalen, is de veiligste link de link die je zelf intypt, of de officiële app. Een wallet-back-up is iets anders: voer die nooit in omdat een bericht daarom vraagt. Trezor zegt nooit om je wallet-back-up te vragen; volg de herstelinstructies van de maker van je eigen wallet.

Hoe Reveal URLs bepaalt wat het markeert

Reveal URLs is mijn eigen gratis en opensource tool, dus lees dit deel als mijn beschrijving van mijn eigen werk. De regel is bewust smal en voorspelbaar:

1. Van de weblinks die het annoteert, toont het de werkelijke directe URL: in Chrome, Edge, Firefox, Safari en Thunderbird direct boven de link; in Gmail als kaart in de zijbalk; en in Outlook in een taakvenster.
2. Als de zichtbare linktekst zelf een URL of host bevat, vergelijkt het dat adres met de werkelijke directe URL op het niveau van het registreerbare domein.
3. Horen ze bij verschillende sites, dan markeert het de bestemming, standaard in rood (een instelling die je kunt aanpassen). Een gewoon subdomein zoals mail.example.com bij example.com wordt met rust gelaten; een lookalike wordt gemarkeerd.
4. Bevat de tekst helemaal geen adres, zoals bij een knop "Nu betalen", dan wordt de bestemming nog steeds getoond, alleen niet rood: er staat geen host in de tekst om mee te vergelijken.

Dit zijn de regels voor het vergelijken van hostnamen bij gewone weblinks. Site-instellingen en uitgesloten hosts kunnen de annotatie uitzetten, en de browser- en Thunderbird-versies hanteren aparte regels voor sommige links die geen weblink zijn: een javascript:- of data:-link wordt altijd gemarkeerd.

De tabel hieronder gebruikt de gereserveerde voorbeelddomeinen example.com, example.net en example.org, omdat Reveal URLs een adres in de linktekst alleen herkent als het eindigt op een echt publiek achtervoegsel. De verzonnen harbourline.example-namen elders in dit artikel illustreren de redenering, niet wat het product laat zien.

Twee dingen doet het bewust niet. Het volgt geen redirects: het laat zien waar de link zelf naartoe wijst, niet waar een tracker, verkorter of inlogdienst je daarna heen stuurt. En het oordeelt niet of een site veilig is. Een link zonder mismatch is niet automatisch veilig. Het ontbreken van rood betekent alleen dat er geen mismatch is gemarkeerd: tekst en bestemming kunnen hetzelfde registreerbare domein delen, maar het kan ook zijn dat Reveal URLs het adres in de tekst niet heeft herkend, of dat een instelling de markering voor die site heeft uitgezet. Zelfs overeenkomende domeinen laten niet zien dat een pagina veilig is. Is de tekst een knop of zijn het woorden zonder adres, dan valt er niets te vergelijken: kijk dan naar de bestemming die Reveal URLs toont.

Hostingplatforms kunnen verschillende mensen een subdomein van één platformdomein geven, zoals alice.github.io en bob.github.io. Reveal URLs vergelijkt op het niveau van het registreerbare domein volgens de ICANN-lijst, dus het markeert het ene niet ten opzichte van het andere, ook al kunnen ze door verschillende mensen worden beheerd. Een gedeeld platformdomein betekent niet dat dezelfde persoon beide pagina's beheert.

Lange URL's worden bij de link ingekort, standaard tot 100 tekens; in de instellingen kun je meer laten tonen. Zie je een beletselteken, bekijk dan het volledige adres voordat je beslist: de browser- en Thunderbird-versies tonen het ook als je met de muis over de getoonde URL gaat. De vergelijking gebruikt altijd de volledige URL, maar volgt die niet.

Daarom kunnen sommige onschuldige gevallen van hierboven toch rood worden: een nieuwsbrieflink die www.example.com noemt maar naar de tracker van een mailingdienst wijst, zoals click.example.org, gaat echt eerst naar een andere site. Het rode kader zegt niet "phishing"; het zegt "tekst en bestemming zijn het niet eens, kijk even". Omgekeerd worden de lastige gevallen uit het vorige deel misschien helemaal niet rood, omdat de directe URL echt van Google of Microsoft is. Juist door die volledige URL te lezen, kun je het tweede adres opmerken dat erin verstopt zit.

Leeftijd van het domein: een extra signaal

De regel die Reveal URLs toepast, vergelijkt de zichtbare tekst van een link met het domein van zijn eigen bestemming. De leeftijd van een domein is een apart signaal, voor jou als lezer om mee te wegen.

Een bank, een pakketdienst of een grote webwinkel heeft zijn domein meestal al jaren. Komt een link die zich voordoet als zo'n gevestigde naam uit bij een domein dat vorige week is geregistreerd, dan is dat verdacht, ook als de naam aannemelijk klinkt en ook als tekst en bestemming overeenkomen. In een analyse uit 2019 stelde Unit 42 van Palo Alto Networks vast dat meer dan 70% van de nieuw geregistreerde domeinen (in hun definitie: geregistreerd of van eigenaar gewisseld in de afgelopen 32 dagen) "malicious", "suspicious" of "not safe for work" was, en dat zulke domeinen vaak door phishingcampagnes worden gebruikt. Hetzelfde rapport noemt ook doodnormale redenen voor een nieuw domein: de lancering van een product, een nieuw merk of een nieuwe campagne, een congres of een persoonlijke site.

Leeftijd is dus een signaal, geen oordeel, in beide richtingen. Een nieuw domein kan volkomen legitiem zijn, en een oud domein kan gekaapt zijn: de Google-campagne hierboven stuurde slachtoffers onder meer naar gecompromitteerde .de-subdomeinen. Leeftijd voegt context toe aan wat je al ziet; het beslist niet in zijn eentje.

Wil je het nakijken, dan toont een opzoekdienst voor registratiegegevens zoals ICANN Lookup de actuele registratiegegevens van een domeinnaam, meestal inclusief de datum waarop die is aangemaakt. En scan je QR-codes: mijn eigen app QR Quishing Detector, binnenkort in Google Play en de App Store, heeft een optionele opzoekfunctie voor de registratieleeftijd van een domein. Die staat standaard uit, en de leeftijd die je te zien krijgt is informatie voor jou: die verandert de risicoscore van de app niet.

Zie de bestemming voordat je klikt

Reveal URLs is gratis en opensource (AGPL-3.0-only). Het is nu beschikbaar voor Chrome, Edge, Firefox, Safari en Thunderbird, als Gmail-add-on, en als Outlook-add-in voor Outlook op het web en op de desktop. De browserextensies en de Thunderbird-add-on doen al hun werk op je eigen apparaat; de Gmail-add-on draait op de servers van Google, omdat Gmail-add-ons nu eenmaal daar draaien.

Een ander domein achter een link is een vraag, geen antwoord. Lees de hostnaam van rechts, zoek het registreerbare domein en vraag je af of dat domein hoort bij wie de tekst noemt. Meer over hoe Reveal URLs werkt lees je in Reveal URLs: phishinglinks herkennen voordat je klikt; waarom mailprogramma's altijd de URL zouden moeten tonen in E-maillink-phishing: waarom je mailprogramma altijd de URL zou moeten tonen; en waarom een echt ogende afzender niet genoeg is in Anti-phishingcode: een nuttig signaal dat je links niet controleert.