Domännamnkapning, DNS-förgiftning och registrarlåsning¶

Att tappa kontrollen över din organisations primära domännamn eller auktoritativa DNS-zon är en av de mest förödande digitala nödsituationer som ett företag, sjukhus, kommunala myndigheter eller onlinepublikationer kan drabbas av. Eftersom ditt domännamn är roten till förtroende för alla system på internet, förstör en angripare som kapar ditt domänregistrarkonto eller förgiftar dina DNS-poster inte bara din webbplats. Inom några minuter efter att du har ändrat din NS (namnserver), A/AAAA (webb-IP), eller MX (Mail Exchange) poster, kan angriparen tyst fånga upp alla inkommande företags- och kunde-postmeddelanden, passera automatisk Let's Encrypt Domain Validation (DV) kontroller för att skapa giltiga TLS/SSL-krypteringscertifikat i ditt namn, fånga anställdas Single Sign-On (SSO) lösenord och utlösa e-postmeddelanden om lösenordsåterställning för din molninfrastruktur, bankportaler och finansiella konton. Även ett icke-skadligt misslyckande, till exempel en utgången domän som hamnar i AutoRenewGracePeriod eller RedemptionPeriod (clientHold), stoppar webbtrafik, API mobila backends och företags e-post omedelbart över hela världen.

Om en domänkapning eller DNS-avbrott äventyrar sjukhusets patientdirigering, nödkommunikation, telemetri eller ett aktivt livsäkerhetssystem, ring ditt lokala nödnummer (911 i USA och Kanada, 112 över hela Europeiska unionen, 999 i Storbritannien) eller konsultera vår katalog över internationella nödnummer och meddela ditt nationella svarsteam för cyberincidenter (som CISA i USA på 1-844-SAY-CISA eller NCSC i Storbritannien) omedelbart. För alla kommersiella, ideella och personliga domänkriser, utför triagestegen nedan i exakt ordning.

Gör det här nu¶

1. Fastställ inom 30 sekunder om din domän har löpt ut, dina DNS-poster har ändrats eller om domänen har överförts till en utländsk registrar: Kör en live RDAP eller WHOIS fråga och en auktoritativ DNS-fråga från en terminal (rdap yourdomain.com eller whois yourdomain.com, och dig +trace yourdomain.com). Kontrollera Registrarnamn, EPP-statuskoder (som t.ex clientHold för fakturering/verifiering vs. ok med okända namnservrar), och de Auktoritativa namnservrarna (NS).
2. Frys alla utgående lösenordsåterställningar och lås din identitetsleverantör (Okta, Microsoft Entra ID, Google Workspace) omedelbart: Om en angripare kontrollerar din domäns MX rekord eller NS servrar får de varenda e-post som skickas till *@yourdomain.com. Instruera omedelbart dina IT-administratörer att inaktivera "Glömt lösenord via e-post" självbetjäningsåterställningar för alla företagsverktyg, återkalla aktiva sessioner för användare vars e-postadresser kan användas för att återställa externa leverantörskonton och byta administrativa inloggningar till hårdvaru-FIDO2-säkerhetsnycklar eller interna .onmicrosoft.com reservdomäner.
3. Bevara fullständiga kriminaltekniska ögonblicksbilder av RDAP/WHOIS, DNS-zoner och certifikattransparens (CT) loggar innan något ändras: Spara utdata från dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, och kontrollera crt.sh/?q=%25.yourdomain.com omedelbart. Sökande crt.sh avslöjar alla obehöriga SSL/TLS-certifikat som angriparen just skapat för dina underdomäner (mail., vpn., login., api.) så att du vet exakt vilka interna tjänster de aktivt imiterar sig via Adversary-in-the-Middle (AitM) proxyservrar.
4. Kontakta den förlorande registrarens dedikerade nödmissbruks-/säkerhetsoperationsteam (inte Tier-1-chattsupport) för att utlösa en ICANN-tvist om obehörig överföring (IRTP) eller återföring av registerlås: Om din domän skickades till ett annat konto hos samma registrar eller överfördes via en stulen Auth-Info (EPP) koden till en utländsk registrar, kontakta din ursprungliga registrars Domänmissbruk / Högrisk Security Escalation Desk och begär en omedelbar Registrar Ångra / Emergency Transfer Dispute enligt ICANN:s överföringspolicy (Section I.A och Transfer Dispute Resolution Policy), med hänvisning till otillåten kompromiss med legitimation.
5. Eskalera direkt till registeroperatören på toppnivådomänen (TLD) om registraren inte svarar: Kom ihåg hierarkin: Registrarer (som GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) är helt enkelt återförsäljare i detaljhandeln; Registeroperatören (som Verisign för .com/.net, Public Interest Registry (PIR) för .org, Nominet för .uk, CIRA för .ca, DENIC för .de, eller auDA för .au) kör huvudrotzonsdatabasen. Landskod (ccTLD) register och flera gTLD-register kan placera en nödsituation serverHold eller serverUpdateProhibited lås direkt på rotnivå under verifierade cyberbrottsincidenter.
6. Varna kunder, leverantörer och bankpartners via kanaler utanför bandet @yourdomain.com e-post har äventyrats: Om angriparen kapade din MX register kommer de omedelbart att svara på öppna bokföringstrådar med falska instruktioner för banköverföring. Meddela kunder via telefon, SMS, LinkedIn, statussida på en separat backupdomän eller officiella sociala mediekonton att de inte litar på någon e-post eller inloggningsportal på den berörda domänen tills återställningen har bekräftats.

Beslutsträd: diagnostisera och innehålla ett domän- eller DNS-avbrott¶

Följ det här snabba diagnostiska flödesschemat för att lokalisera det exakta lagret av domännamnssystemet som har misslyckats eller kapats:

flowchart TD
    A["Webbplats nere, TLS-certifikatvarning eller företags-e-post stoppad"] --> B["Kör RDAP/WHOIS och gräv +spåra från externt nätverk"]
    B --> C{"Vad visar RDAP-status och registrarfält?"}
    C -->|"Status: clientHold, autoRenewPeriod eller redemptionPeriod"| D["Oavsiktligt utgångsdatum eller ICANN Whois Verification Suspension"]
    D --> E["Logga in på registratorn omedelbart: Betala förnyelse-/inlösenavgift eller klicka på RAA-verifieringslänk; Begär nödspolning med TTL"]
    C -->|"Registrarnamn eller registrantkonto har ändrats utan auktorisering"| F["Fullständig kapning av registrarkonto eller obehörig EPP-överföring"]
    F --> G["Lås identitetsleverantör (Entra/Google), missbruksbiljett för nödregistrator + ICANN-överföringstvist, kontrollera crt.sh för falska certifikat"]
    C -->|"Registrar & NS oförändrade, men A/CNAME/MX-poster pekar på okända IP-adresser"| H["Kompromiss med hanterad DNS-leverantör (Cloudflare / Route53 / NS1 API-nyckel eller kontobrott)"]
    H --> I["Återkalla komprometterade DNS API-tokens, återställ känd-bra zonfil, återkalla Rogue TLS-certifikat, rotera exponerade autentiseringsuppgifter"]
    C -->|"Registrar, NS och Zone Records ser normala ut, men webbplatsen misslyckas med SERVFAIL"| J["Bruten DNSSEC Chain of Trust (DS Record Mismatch eller Expired RRSIG)"]
    J --> K["Kör DNSViz.net-kontroll: Ta bort inaktuell DS-post hos registrator eller återsigna zon på DNS-värd"]

Fas 1: Teknisk kriminalteknik för att identifiera den exakta attackvektorn¶

När en domän plötsligt slutar lösas eller börjar visa en nätfiskesida eller bedrägeri med kryptovaluta, slösar varje minut som ägnas åt att gissa dyrbar återhämtningstid. Det finns fyra helt distinkta scenarier som ser identiska ut med en slutanvändare i en webbläsare, och var och en kräver en helt annan fix.

Hur man läser RDAP, WHOIS, och dig Skickar ut som en incidentsvarare¶

Öppna en kommandoterminal på Linux, macOS eller Windows (med WSL eller nslookup) och kör följande tre diagnostiska kontroller med en neutral offentlig rekursiv resolver (8.8.8.8 eller 1.1.1.1):

1. Kontrollera delegeringen på registernivå (dig +trace och RDAP):

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Titta på steget direkt efter TLD-rotservrarna (till exempel, a.gtld-servers.net. för .com). Vilket NS (Namnserver) värdnamn returneras av själva TLD-registret?
   • Om TLD-registret returnerar dina vanliga namnservrar (ns1.yourdnsprovider.com) med status NOERROR, sker kapningen inuti din DNS-värdleverantör (eller så är det ett DNSSEC-brott).
   • Om TLD-registret returnerar helt okända namnservrar (eller om whois yourdomain.com visar en ny Registrar: namn och ett Updated Date: under de senaste timmarna eller dagarna), hände kapningen på domänregistrarnivå.
2. Avkoda ICANN EPP-domänstatuskoderna: Titta på Domain Status: linjer i din WHOIS eller RDAP utgång. Dessa standardiserade EPP-koder (Extensible Provisioning Protocol) berättar varför en domän inte fungerar eller är låst:

Fas 2: Återställning från en skadlig domänkapning eller obehörig registraröverföring¶

Angripare kapar värdefulla företags-, Web3/DeFi-, finans- och mediadomäner med hjälp av tre primära tekniker: 1. Registrar Account Takeover (Credential Stuffing, Infostealer Malware eller SIM Swap): Angriparen loggar in på din GoDaddy, Namecheap, Google Domains/Squarespace eller Network Solutions instrumentpanel, stängs av clientTransferProhibited, ändrar NS poster för att peka på ett angriparkontrollerat Cloudflare-konto, eller genererar ett Auth-Info (EPP) kod för att överföra domänen ut. 2. Social Engineering of Registrar Support: Angriparen skickar in förfalskade inkorporeringsdokument, falska myndighets-ID eller falska brevpapper till en registrars kontoåterställningsdisk och hävdar att den ursprungliga IT-administratören dog eller lämnade företaget. 3. ** Underdomänövertagande (Dangling CNAME / Dangling NS)**: Din huvuddomän är orörd, men en gammal underdomän (promo.yourdomain.com eller status.yourdomain.com) har fortfarande en CNAME post som pekar på en avvecklad AWS S3-bucket, Azure App Service, GitHub Pages repo, Heroku-app eller Zendesk-instans som du tog bort för månader sedan. Angriparen registrerar det övergivna molnresursnamnet på AWS/Azure/GitHub och serverar omedelbart skadligt innehåll från din officiella underdomän.

Steg 1: Avvisa angriparen från din molnidentitetsleverantör och e-postsystem¶

Innan du ens har fyllt i registraråterställningsformuläret, anta att angriparen aktivt läser varje e-postmeddelande som skickas till din domän och försöker svänga in i din interna molninfrastruktur:

1. Byt Microsoft 365/Google Workspace till reservdomäner och MFA för maskinvara:
   • I Microsoft Entra ID (tidigare Azure AD) har varje hyresgäst en permanent reservdomän som inte kan kapas (yourcompany.onmicrosoft.com). Administratörer kan logga in via admin@yourcompany.onmicrosoft.com även om yourdomain.com DNS är fullständigt kapad.
   • Inaktivera alla metoder för återställning av SMS, röstsamtal och alternativa e-postlösenord i Entra ID / Okta / Google Workspace (Authentication Methods Policy). Kräv FIDO2/WebAuthn hårdvarusäkerhetsnycklar eller nummermatchande Authenticator-pushnotiser.
2. Granska utgående och inkommande e-postloggar för det exakta kompromissfönstret:
   • Om din MX posterna ändrades 02:14 UTC, noll legitima externa e-postmeddelanden har nått dina riktiga e-postservrar sedan 02:14 UTC; varenda extern e-post som skickades till din personal under det fönstret fångades in i full klartext av angriparens oseriösa e-postserver (Postfix/Exim-lyssnare).
   • Ta omedelbart fram en lista över alla tredjeparts SaaS-plattformar, banker, AWS/GCP-rotkonton, GitHub-organisationer och leverantörsportaler som är kopplade till @yourdomain.com e-postadresser och kontrollera om angriparen utlöste lösenordsåterställningar på dessa externa plattformar under kapningsfönstret.

Steg 2: Kör protokollet Registrar and Registry Emergency Recovery¶

Öppna inte en generisk "Min webbplats fungerar inte" supportchatt. Du måste använda den exakta reglerande och juridiska terminologin som utlöser eskalering till Registrar Tier-3 Security / General Counsel / ICANN Compliance Team:

1. Fall A: Domänen finns fortfarande hos din ursprungliga registrator (kontoövertagande eller intern "kontopush"):
   • Många angripare väntar inte 5 dagar på en EPP-överföring mellan registrarer; istället använder de registrarens omedelbara "Push Domain to Another Account"-funktion för att flytta din domän till ett brännarkonto hos samma registrar på 3 sekunder.
   • Ring och maila omedelbart registrarens bedrägeri-/kontokapning/missbruksavdelning. Ange tydligt: "BRÄNDSK SÄKERHETSINCIDENT: obehörig kontoåtkomst och intern domän-push/DNS-ändring av [dindomän.com]. Begär omedelbar frysning av domänen enligt serverHold/clientUpdateProhibited och återställning av obehöriga DNS/kontoändringar."
   • Sätt ihop ditt paket med bevis på historiskt ägande direkt: Registratorsäkerhetsteam kräver obestridliga bevis på att du är den legitima tidigare registranten innan de kan dra tillbaka en domän från ett annat konto. Samla dessa 5 dokument till en enda PDF direkt:
     1. Historiska registrarfakturor och betalningsbevis: PDF-kvitton och kreditkorts-/bankutdrag som visar att din organisation betalar för registrering och förnyelse av yourdomain.com under de senaste 1 till 10 åren (inklusive de fyra sista siffrorna i betalkortet eller bankreferensen).
     2. Statligt utfärdat företagsregistrerings- och tjänstemanna-ID: Officiellt bolagsbevis / bolagsordning som matchar den historiska WHOIS Registrant Organization, plus en statlig fotolegitimation av den företagstjänsteman som undertecknar intyget.
     3. Historiskt bevis på DNS-zonfil och serverägande: Kopior av din tidigare DNS-zonfil, historiska WHOIS-ögonblicksbilder eller bevis på att din organisation äger det autonoma systemet (ASN) eller IP-block (A poster) som domänen pekade på i flera år före dagens förändring.
     4. E-post/biljetthistorik för att skapa originalkonto: Rubriker på e-postmeddelanden som mottogs från registraren vid den tidpunkt då domänen ursprungligen registrerades eller förnyades.
     5. Officiellt polisnummer: En inlämnad FBI IC3 (ic3.gov) klagomålsnummer (USA), Action Fraud referensnummer (Storbritannien) eller nationell polisens cyberbrottsrapportnummer. Registratorer agerar dramatiskt snabbare när de får ett formellt brottsbekämpande ärendenummer som bekräftar ett kriminellt datorintrång under 18 U.S.C. § 1030 (CFAA) eller UK Computer Misuse Act 1990.
2. Fall B: Domänen överfördes till en annan registrar (Inter-Registrar Hijack):
   • Enligt ICANN Transfer Policy (tidigare IRTP) kräver en överföring mellan registrarer en Auth-Info (EPP) kod och måste blockeras i 60 dagar efter vissa registrantändringar såvida de inte avsägs. Om en angripare hackade ditt konto hos Registrar A ("den förlorande registratorn") och överförde domänen till Registrar B ("den vinnande registratorn"):
   • Kontakta BÅDE den förlorande registraren och den vinnande registratorn omedelbart, men prioritera Tvisten/säkerhetsteamet för den förlorande registrarens överföring. Enligt ICANN:s Transfer Dispute Resolution Policy (TDRP) är den förlorande registratorn den enhet som har dina historiska faktureringsuppgifter och inloggningsloggar som bevisar att överföringen var otillåten. Den förlorande registratorn kan formellt kontakta den vinnande registrarens efterlevnadsansvarige för att genomföra en kooperativ Registrar Transfer Undo, eller lämna in ett formellt TDRP-förfarande.
   • Skicka samtidigt ditt paket för äganderättsbevis och polisrapport till Gaining Registrar's Abuse Desk och kräver att de lägger en omedelbar clientTransferProhibited och clientUpdateProhibited lås på domänen så att angriparen inte kan hoppa domänen genom en kedja av ytterligare tre offshore-registratorer ("registrar hopping").
3. Skicka in en nödupptrappning med ICANN (för gTLDs som .com, .net, .org, .io if gTLD) eller ccTLD-registret:
   • Om en registrar vägrar att undersöka en obehörig överföring eller inte svarar under en aktiv kapning, skicka in ett brådskande klagomål om obehörig överföring/domänkapning via ICANN Contractual Compliance Portal (icann.org/compliance/complaint).
   • Om din domän använder en Toppnivådomän med landskod (ccTLD), såsom .uk, .ca, .au, .de, .fr, .nl, .ch, eller .jp, du har ett ännu snabbare alternativ: ccTLD-register styrs av nationella tillsynsmyndigheter snarare än ICANN och upprätthåller nästan alltid direkta Registry Emergency Security Teams (till exempel Nominet i Storbritannien kl. 0330 236 9470, CIRA i Kanada, DENIC i Tyskland, AFNIC i Frankrike) som kan frysa en kapad domän direkt på nationell registernivå inom några timmar efter verifiering av företagets identitet.

Fas 3: Rädda en utgången domän (clientHold, RedemptionPeriod, och PendingDelete)¶

Inte varje plötsligt globalt avbrott är en cyberattack. Varje dag blir stora företag, SaaS-startups och statliga entreprenörer helt mörka eftersom kreditkortet som registrerats hos deras domänregistrator gick ut och e-postmeddelandena om förnyelsepåminnelser skickades till former-founder@company.com som lämnade företaget för tre år sedan.

Förstå ICANN Expired Domain Lifecycle Timeline¶

För generiska toppdomäner (.com, .net, .org, .biz, .info), tillämpar ICANN Expired Registration Recovery Policy (ERRP) en strikt livscykel i flera steg efter att utgångsdatumet har passerat:

1. Steg 1: Respitperiod för automatisk förnyelse (dagar 1 till ~30/45 efter utgången):
   • Omedelbart efter utgången (ofta inom 24 till 72 timmar), ändrar registraren domänens NS registrerar till en parkerad/förfallen förnyelsesplash-sida eller placerar domänen på clientHold.
   • Påverkan: Din webbplats och företagets e-post slutar fungera omedelbart (DNS_PROBE_FINISHED_NXDOMAIN eller parkeringsannonser).
   • Återställning: Logga in på registrarkontot och betala standardavgiften för ett år för förnyelse ($10 till $30 USD). Registraren återställer omedelbart ditt original NS rekord.
2. Steg 2: Respitperiod för inlösen (redemptionPeriod, 30 dagars varaktighet):
   • Om ingen förnyar domänen under steg 1 (vanligtvis efter dag 30 till 42 beroende på registrarens användarvillkor), tar registraren bort domänen i registret och registret placerar den i den obligatoriska 30-dagars redemptionPeriod (såvida inte registraren auktionerade ut den förfallna domänen via en intern auktionsplattform för utgått domän som GoDaddy Auctions eller NameJet, kontrollera din registrars exakta dag-30 auktionstid omedelbart).
   • Återställning: Du kan fortfarande rädda domänen med 100 procents säkerhet under redemptionPeriod, endast genom den ursprungliga Losing Registrar. Du måste kontakta deras fakturerings-/supportdesk och betala Registry Redemption Restore Fee (vanligtvis $80 till $250 USD) plus en 1-års förnyelse.
3. Steg 3: Väntar på borttagning (pendingDelete, sista 5 kalenderdagarna):
   • En gång i 30-dagarna redemptionPeriod går ut, domänen går in pendingDelete i exakt 5 dagar (120 timmar).
   • Påverkan: Under pendingDeleteregistret avvisar alla standard-EPP restore kommandon från registratorn. I slutet av dag 5 (för .com/.net Verisign släpper, mellan 18:00 och 19:15 UTC), släpps domänen till allmänheten och ryckas inom 10 millisekunder av automatiska drop-catching-nätverk.
   • Nödåtgärd om fastnat pendingDelete eller Registrar Expired Auction:
     • Om domänen såldes via registrarens dag-30 utgångna auktion innan du gick in i registret redemptionPeriod, kontrollera om din registrar erbjuder ett kort inlösenfönster efter auktionen eller kontakta den vinnande budgivaren/mäklaren omedelbart.
     • Om domänen verkligen är i 5-dagarsregistret pendingDelete fas, placera samtidigt high-tier restorder över alla tre stora drop-catching-nätverk (DropCatch.com, SnapNames.com, och NameJet.com) så att om domänen faller till den offentliga poolen på dag 5, fångar din restorder den eller går in i den stängda budauktionen för att köpa tillbaka din domän.

Varför misslyckas min webbplats fortfarande i timmar efter att jag förnyat en utgången domän? (Åtgärda negativ DNS-cache)¶

När din domän löper ut ersätter registraren din NS poster med tillfälliga parkeringsnamnservrar som ofta har en 24-timmars till 48-timmars TTL (Time-To-Live) (86400 eller 172800 sekunder). Även efter att du har betalat förnyelseräkningen och din registrar återställer din riktiga NS registrerar i rotzonen inom 5 minuter, offentliga rekursiva DNS-lösare över hela världen (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, och ISP-lösare) kan fortsätta att visa den cachade utgångna parkeringssidan tills den 48-timmars TTL löper ut.

Hur man tvingar fram en omedelbar global DNS-cache-spolning på 60 sekunder: Vänta inte i 48 timmar tills rekursiva cacheminner förfaller naturligt. Spola manuellt din domän från de tre största globala offentliga DNS-leverantörerna just nu med hjälp av deras gratis webbcache-rensningsportaler: 1. Ta bort Google Public DNS (8.8.8.8 / 8.8.4.4): Besök developers.google.com/speed/public-dns/cache, typ yourdomain.com, välj posttyp NS (och upprepa sedan för A, AAAA, MX, och DS), och klicka på Spola cache. Detta rensar din domän i alla Googles DNS-datacenter över hela världen på mindre än 10 sekunder. 2. Spola Cloudflare Public DNS (1.1.1.1 / 1.0.0.1): Besök one.one.one.one/purge-cache/, ange yourdomain.com, välj NS, A, AAAA, och MX och klicka på Rensa cache. 3. Spola OpenDNS / Cisco Umbrella (208.67.222.222): Besök cachecheck.opendns.com, ange yourdomain.com, kontrollera resultaten över globala noder och klicka på Uppdatera cachen längst ned i tabellen.

Fas 4: Åtgärda trasig DNSSEC (SERVFAIL) efter en migrering eller kapning¶

Domain Name System Security Extensions (DNSSEC) signerar dina DNS-poster kryptografiskt (RRSIG poster signerade av en zonsigneringsnyckel ZSK och nyckelsigneringsnyckel KSK) och publicerar en matchande Delegation Signer (DS) hash i den överordnade TLD-zonen hos din registrar.

Medan DNSSEC förhindrar cacheförgiftning, orsakar en trasig DNSSEC-konfiguration ett omedelbart, totalt globalt avbrott (SERVFAIL) på varje validerande resolver (inklusive 8.8.8.8, 1.1.1.1, Comcast och större mobiloperatörer). Detta händer oftast under en nödmigrering: en administratör flyttar yourdomain.coms namnservrar från Cloudflare till AWS Route 53 (eller vice versa) utan att först radera den gamla leverantörens DS registrera hos domänregistratorn.

Diagnostisera och reparera en DNSSEC SERVFAIL Lockout på 5 minuter¶

1. Bekräfta att DNSSEC är boven: Kör två dig kommandon back-to-back: en normal fråga och en fråga med +cd (Checking Disabled) flagga, som talar om för den rekursiva resolvern att ignorera DNSSEC kryptografisk validering:

   dig yourdomain.com @8.8.8.8
   dig yourdomain.com @8.8.8.8 +cd
   

   • Om det första kommandot misslyckas med status: SERVFAIL och noll svar, medan det andra kommandot (+cd) omedelbart lyckas med status: NOERROR och returnerar din A registrera IP-adress, 100 procent av ditt avbrott är en trasig DNSSEC-förtroendekedja.
2. Inspektera det exakta brottet med DNSViz.net eller Verisign DNSSEC Debugger:
   • Öppna dnsviz.net eller dnssec-debugger.verisignlabs.com och gå in yourdomain.com.
   • Den kommer att rita ett visuellt diagram som visar om DS post som publicerats hos din registrar stämmer inte överens med DNSKEY betjänas av din nuvarande DNS-värd, eller om dina zonsignaturer (RRSIG) har gått ut.
3. Nödsanering:
   • Om du precis har bytt DNS-leverantör: Logga in på din Domänregistrator, navigera till avsnittet DNSSEC / DS Records och radera den gamla inaktuella DS spela in (eller ersätt den med den nya DS post genererad av din nya DNS-värd).
   • ** Spola av DS record cache**: Besök omedelbart Google Public DNS Cache Flush (developers.google.com/speed/public-dns/cache) och Cloudflare Purge Cache (one.one.one.one/purge-cache/) och rensa DS och DNSKEY posttyper för yourdomain.com så att validera resolvers sluta kontrollera de borttagna DS hash omedelbart.

Fas 5: Rengöring efter återhämtning, återkallande av TLS-certifikat och härdning¶

Att få tillbaka ditt domänregistrarkonto och DNS-poster under din kontroll är bara halva striden. Under de timmar eller dagar som angriparen kontrollerade din domäns DNS, hade de fullständig auktoritet att bevisa "Domain Control Validation" (DCV) till varje certifikatutfärdare (CA) på planeten.

1. Granska certifikattransparensloggar (crt.sh) och återkalla Rogue TLS-certifikat¶

När en angripare pekar din A eller NS poster till sin server kör de omedelbart certbot (Låt oss kryptera, ZeroSSL, Google Trust Services eller Sectigo) för att generera giltiga, webbläsarbetrodda TLS-certifikat för yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, och mail.yourdomain.com. Även efter att du har återställt dina DNS-poster har angriparen fortfarande den giltiga Private Key (.key) och undertecknat Offentligt intyg (.crt) för din domän, som de kan använda för att arrangera captive-portal Wi-Fi-attacker, BGP-kapningar eller intern nätverkspoofing under de kommande 90 dagarna.

1. Fråga certifikattransparensloggar:
   • Gå till crt.sh/?q=%25.yourdomain.com eller Censys Certificate Search (search.censys.io/certificates).
   • Sortera efter Logged At / Not Before datera och inspektera varje enskilt certifikat som utfärdats under kapningsfönstret (och inom 24 timmar efter återställning, på grund av cachade DCV-auktoriseringar).
2. Tvinga omedelbar återkallelse av certifikat:
   • Identifiera den utfärdande certifikatutfärdaren (Issuer Name) på varje obehörigt certifikat.
   • Varje offentligt betrodd CA krävs enligt CA/Browser Forum Baseline Requirements (avsnitt 4.9.1.1) för att återkalla ett bedrägligt eller obehörigt certifikat inom 24 timmar efter att ha bekräftat att sökanden inte var auktoriserad av den sanna domänägaren.
   • Om du redan har återfått DNS-kontrollen över domänen kan du själv återkalla obehöriga Let's Encrypt- eller ACME-certifikat på 60 sekunder utan att ens behöva angriparens privata nyckel: installera helt enkelt certbot på en server du kontrollerar, klara en ny DNS-01- eller HTTP-01-utmaning för exakt samma domännamn med en helt ny ACME-kontonyckel och kör:

     certbot revoke --cert-path downloaded_rogue_cert_from_crt_sh.pem --reason keycompromise
     

   • Alternativt kan du skicka in certifikatets serienummer direkt till CA:s portal för nödåterkallelse (till exempel Let's Encrypts sida för återkallelseinstruktion, DigiCerts /revoke portal eller Sectigos rapporteringsformulär för SSL-missbruk).

2. Lås ner din domän permanent så att den aldrig kan kapas igen¶

När verksamheten har återställts implementerar du dessa fem företagsdomänhärdande kontroller:

1. Aktivera registerlås (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited):
   • För verksamhetskritiska produktionsdomäner, uppgradera till en registrar som erbjuder äkta Registry Lock (stöds av Verisign på .com/.net, PIR på .org, och erbjuds genom företagsregistratorer som MarkMonitor, CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock-nivåer). Med Registry Lock aktivt, även om en hacker stjäl din registrarinloggning och MFA, avvisar TLD-registret alla NS eller överföringsändringar såvida inte en mänsklig säkerhetsansvarig genomför en kryptografisk/telefonceremoni utanför bandet.
2. Publicera CAA (Auktorisering av certifikatutfärdare) DNS-poster:
   • Lägg till en CAA spela in (RFC 8659) till din DNS-zon och anger de exakta certifikatutfärdare som får utfärda TLS-certifikat för din domän (t.ex. 0 issue "letsencrypt.org" eller 0 issue "digicert.com", plus 0 iodef "mailto:security@yourdomain.com"). Medan en angripare som kontrollerar hela din DNS-zon kan ta bort en CAA rekord, a CAA post stoppar BGP-kapare eller komprometterade CNAME-mål under domän från att använda obehöriga certifikatutfärdare.
3. Separera din domänregistrator från din dagliga DNS-värdleverantör:
   • Håll din domänregistrering låst i ett högsäkerhetsvalvregistrarkonto som endast 2 företagstjänstemän kan komma åt med FIDO2 hårdvarusäkerhetsnycklar (YubiKey), och delegera daglig DNS-posthantering (A, CNAME, TXT) till en separat hanterad DNS-tjänst med granulär rollbaserad åtkomstkontroll (RBAC) och scoped API-tokens.
4. ** Granska och eliminera dinglande underdomän CNAME och NS Rekord**:
   • Kör en månatlig automatisk genomsökning av hela din DNS-zonfil (subzy, nuclei -t takeovers/, eller OWASP Amass) för att identifiera någon CNAME, ALIAS, eller underdomän NS post som pekar på en oregistrerad extern molnresurs eller utgången domän, och radera DNS-posten innan avveckla molnservern.
5. Konfigurera automatisk extern RDAP-, DNS- och CT-loggövervakning:
   • Konfigurera en extern bildskärm (t.ex CertSpotter, Cloudflare Certificate Transparency Monitoring, eller en enkel cron-skriptkontroll varje timme dig NS och whois) som varnar en dedikerad Slack/PagerDuty-kanal och en SMS/e-postadress utanför domänen exakt samma minut som ett nytt TLS-certifikat loggas in i Certificate Transparency eller en NS/MX/DS registrera ändringar.

Vanliga frågor¶

Källor kontrollerade¶

• Cybersecurity and Infrastructure Security Agency (CISA, USA): Nöddirektiv 19-01: Begränsa DNS Infrastructure Tampering (CISA-mandat om Registry Lock, MFA för DNS/registratorer, certifikattransparenslogggranskning och DNSSEC-validering) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Överföringspolicy (Inter-Registrar Transfer Policy / IRTP), Transfer Dispute Resolution Policy (TDRP), Expiration Registration Recovery Policy (ERRP) och EPP Status Codes Reference (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• National Institute of Standards and Technology (NIST, USA): Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide (csrc.nist.gov).
• National Cyber Security Center (NCSC, Storbritannien): Skyddar masspersonuppgifter och domänsäkerhet: registerlås, CAA-poster och förebyggande av övertagande av underdomän (ncsc.gov.uk).
• CA/webbläsarforum (internationellt): Baslinjekrav för utfärdande och hantering av offentligt betrodda TLS-servercertifikat (avsnitt 4.9.1.1: 24-timmars obligatorisk återkallelse för domänkompromettering) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS Certification Authority Authorization / CAA Resource Record), och RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

Relaterade guider¶

• Kris för webbhotell, migrering och återställning av säkerhetskopiering
• Nätfiske och intrång i konton
• MFA-nätfiske och motståndare-i-mitten-bypass
• Respons på dataintrång och lösenordsläckor
• Business ransomware och serverintrång
• SIM-byte