Lookalike‑domæner: registreringsdata og certifikatlogs som dokumentation

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Et lookalike-domæne dokumenteres teknisk med tre typer kilder: registreringsdata (RDAP eller WHOIS), der viser hvornår og hos hvem domænet er registreret; DNS-opslag, der viser hvad domænet peger på, og om det kan sende og modtage mail; og Certificate Transparency-logs, der viser hvornår der er udstedt TLS-certifikater til domænet. Tilsammen kan de datere, hvornår domænet blev taget i brug. De kan sjældent sige, hvem der står bag, og det skal stå klart i dokumentationen.

Rollefordeling, advarsel til kunder og klagevej for virksomheden står på søstersitet: Lignende domæne: virksomhedens handleplan. Bevisførelse og rettigheder til navnet behandler advokatsitet i Domænetvister: dokumentation af brug og registrering. Denne artikel går et lag dybere: felterne i RDAP-svaret, DNS-posterne og certifikatlogs, hvordan de hentes reproducerbart, og hvor tolkningen fejler. Om en konkret mail er ægte, vurderes efter den samlede metode, og skelnen mellem lookalike, spoofing og overtaget konto står i Kompromitteret konto, spoofing eller lookalike-domæne?.

Typer af lookalike-domæner

Typen afgør, hvordan domænet beskrives i rapporten, og hvordan søgningen efter beslægtede domæner bygges op:

Redigeringsafstand: indsættelse, sletning, ombytning eller udskiftning af ét tegn. Angiv afstanden til det rigtige navn, fx som Levenshtein-afstand, så forvekslingsgraden er målbar.
Homoglyffer i ASCII: tegnkombinationer, der ser ens ud i almindelige skrifttyper, som “rn” og “m” eller tallet 0 og bogstavet O.
IDN-homoglyffer: tegn fra fx kyrillisk eller græsk, der gengives som latinske bogstaver. I DNS og i certifikater står navnet i punycode med præfikset xn--, og begge former skal dokumenteres, fordi værktøjer viser dem forskelligt.
Anden topdomæne-endelse: samme andenniveau-navn under en anden endelse.
Kombinationsdomæner: det rigtige navn med et tilføjet ord eller en bindestreg.

Når domænet ses i en mail, afgøres det i headerne, om afsenderen brugte lookalike-domænet, forfalskede det rigtige domæne eller sendte fra en overtaget konto. → Kompromitteret konto, spoofing eller lookalike-domæne?

Registreringsdata: RDAP og WHOIS

RDAP (Registration Data Access Protocol) er afløseren for WHOIS. Svaret er struktureret JSON med felter for registrator, status, navneservere og hændelser som registrering, seneste ændring og udløb. WHOIS giver de samme oplysninger som fritekst i et format, der varierer mellem registries.

Registrantens navn og kontaktoplysninger er for de fleste domæner skjult eller erstattet af en privatlivstjeneste. For .dk-domæner er udgangspunktet det modsatte: Punktum dk, der administrerer .dk, viser som hovedregel registrantens navn, adresse og telefonnummer i sin whois-database, og kun personer med navne- og adressebeskyttelse kan være anonyme. Selv når registranten er skjult, er registreringstidspunkt, registrator og navneservere som regel synlige, og de er ofte de vigtigste felter.

Sikring:

Gem det rå svar, både JSON fra RDAP og teksten fra WHOIS, ikke kun et skærmbillede af en webside.
Notér hvilken server der blev spurgt, tidspunktet i UTC og fra hvilken maskine.
Beregn hashværdi af den gemte fil.
Gentag opslaget med faste mellemrum. Registreringsdata kan ændres, og domænet kan skifte registrator.

DNS: hvad peger domænet på?

Et DNS-opslag viser domænets aktuelle opsætning. De relevante poster er:

NS · Navneservere, dvs. hvor domænets DNS administreres
A og AAAA · IP-adresser for websitet
MX · Hvor mail til domænet modtages
TXT · SPF, DMARC og verifikationer for tjenester
SOA · Administrativ post; serienummeret ændres ofte, når zonen ændres

Mailopsætningen vurderes post for post. En MX-post viser modtagelse. En SPF-post i TXT viser, hvilke servere der må afsende, og en DKIM-nøgle under en selektor (<selektor>._domainkey) viser, at signering er sat op; selektoren kendes typisk først fra en modtaget mail. En DMARC-post under _dmarc kan afsløre en rapportadresse, som er en selvstændig oplysning. Et domæne med MX, SPF og DKIM er klargjort til udgående mail, mens en parkeringsside med standard-DNS fra registratoren ikke er det. Gem hvert svar med forespurgt navneserver, tidspunkt i UTC, TTL og SOA-serienummer, og spørg både de autoritative navneservere og en almindelig resolver, så forskelle fra cache kan ses. → Mail-headere, SPF, DKIM og DMARC

Passiv DNS-historik fra kommercielle tjenester viser, hvilke adresser et domæne har peget på tidligere, baseret på observationer fra sensorer. Den kan være nyttig til at datere ændringer, men dækningen er ujævn, og det er tjenestens observationer, ikke en autoritativ historik. Angiv kilde og opslagstidspunkt, og brug den som supplement.

Certificate Transparency

Udstedere af offentligt betroede TLS-certifikater logger i praksis certifikaterne i offentlige Certificate Transparency-logs, fordi de udbredte browsere ellers ikke godtager dem. Søgetjenester gør loggene søgbare på domænenavn. Et opslag kan vise:

hvornår det første certifikat for domænet blev udstedt, ofte tæt på tidspunktet, hvor en webside blev sat op,
hvilke underdomæner der står i certifikaterne, fx login, mail eller webmail,
hvilken udsteder der blev brugt, og hvor ofte certifikatet er fornyet.

Et certifikat er udstedt, når domæneejeren eller en hostingtjeneste har bevist kontrol over domænet. Det viser derfor, at nogen havde teknisk kontrol på det tidspunkt. Det viser ikke, at en side faktisk var online, eller hvad den indeholdt. CT-logs indeholder også såkaldte forhåndscertifikater, så det samme certifikat kan optræde to gange. Søgninger på mønstre som virksomhedens navn kan desuden finde andre lookalike-domæner, der endnu ikke er brugt.

Indholdet på domænet

Websitet sikres som HTTP-trafik, ikke som billede: WARC-formatet bevarer anmodning, svarkode, svarheadere, eventuelle omdirigeringer og indhold med tidspunkt, og serverens IP-adresse og TLS-certifikat på hentetidspunktet bør gemmes ved siden af. Brug en isoleret analysemaskine og en udgående adresse, der ikke kan føres tilbage til virksomheden, og send aldrig data gennem sidens formularer. → Webarkivering i forensisk kvalitet

Hvad kan der siges om ophav?

Her ligger den største faldgrube. Tekniske kilder kan ofte vise sammenhænge, men sjældent identitet:

Delt infrastruktur: To lookalike-domæner på samme IP-adresse kan høre sammen, men en delt hostingserver har tusindvis af domæner.
Samme registrator og tidspunkt: Domæner registreret hos samme registrator inden for minutter kan pege på samme afsender, men det er en indikation.
Samme navneservere, certifikatmønstre eller DKIM-nøgler kan understøtte en sammenhæng.
Registrantoplysninger kan være falske, selv når de er synlige.

Formulér derfor konklusioner som sammenhænge mellem domæner og hændelser, ikke som identifikation af personer. Identiteten bag en skjult registrering kan i nogle tilfælde kræve oplysninger fra registrator, og det er en juridisk vej, ikke en teknisk.

Typiske fejlkilder

Tidszoner: RDAP angiver typisk tidspunkter i UTC, WHOIS-tekst kan variere, og søgetjenester for CT-logs kan vise lokal tid.
Cache: En almindelig resolver kan svare med en gemt værdi, der er ændret hos den autoritative navneserver.
Geografisk forskellige svar: Nogle domæner svarer forskelligt afhængigt af, hvor forespørgslen kommer fra. Notér den udgående adresse, opslaget er lavet fra.
Registry og registrator: For mange endelser findes der både et registry og en registrator med hver sit svar. Det er registryets svar, der er autoritativt for registreringstidspunkt og status.
Genregistrering: Et domæne kan være udløbet og registreret på ny. Oprettelsesdatoen i registreringsdata gælder så den nye registrering, mens webarkiver og CT-logs kan vise aktivitet fra den tidligere indehaver.
Automatiske certifikater: Hostingtjenester udsteder certifikater automatisk, også for parkerede domæner. Et nyt certifikat beviser altså kun domænekontrol, ikke at en falsk side er gået i luften.

Opfølgning over tid

Overvågningen bygges som en serie af identiske målinger: samme forespørgsler, samme navneservere, samme udgående adresse, med rå svar og hash for hver kørsel. Sammenlign SOA-serienummer, NS, MX, A-poster og CT-fund mellem kørslerne, og registrér hver forskel som en hændelse. Et skift kan kun dateres til vinduet mellem to kørsler, så intervallet bestemmer præcisionen og skal stå i rapporten.

Tidslinje

Tidslinjen samler hændelser fra kilder med hver sin præcision: RDAP-hændelsen for registrering (registryets tid), CT-loggens tidsstempel for indlogning, DNS-ændringer dateret til et måleinterval, Received-headere i den første mail og kundens egen hændelse. Normalisér alt til UTC, og angiv for hver post kilde og usikkerhed. Afstanden mellem registrering og første mail er ofte det tekniske fund, der vægter tungest.

Dokumentation

Rapporten bør indeholde domænet i både vist form og punycode, de rå svar fra RDAP eller WHOIS, DNS-svar med navneserver og tidspunkt, CT-fund med certifikatets serienummer og udsteder, eventuel passiv DNS med kilde, websikringen og hashværdier af alle filer. Beskriv for hver kilde, hvad den ikke kan vise.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Password spray og brute force: mønstre i loginloggen · Fakturasvindel: hvilken af parterne var kompromitteret?

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Eller kontakt os på