Domain name hijacking, DNS poisoning, and registrar lockout¶

Losing control of your organization's primary domain name or Authoritative DNS zone is one of the most devastating digital emergencies a business, hospital, municipal agency, or online publication can suffer. Because your domain name is the root of trust for every system on the internet, an attacker who hijacks your domain registrar account or poisons your DNS records does not merely deface your website. Within minutes of changing your NS (Nameserver), A/AAAA (Web IP), or MX (Mail Exchange) records, the attacker can silently intercept every incoming corporate and customer email, pass automated Let's Encrypt Domain Validation (DV) checks to mint valid TLS/SSL encryption certificates in your name, capture employee Single Sign-On (SSO) passwords, and trigger password-reset emails for your cloud infrastructure, banking portals, and financial accounts. Even an non-malicious failure, such as an expired domain falling into AutoRenewGracePeriod edo RedemptionPeriod (clientHold), brings web traffic, API mobile backends, and company email to an instant halt across the globe.

If a domain hijacking or DNS outage compromises hospital patient routing, emergency dispatch communications, public utility telemetry, or an active life-safety system, call your local emergency number (911 Estatu Batuetan eta Kanadan, 112 Europar Batasun osoan, 999 Erresuma Batuan) edo kontsultatu gure nazioarteko direktorioa larrialdi zenbakiak and notify your national cyber incident response team (such as CISA in the United States at 1-844-SAY-CISA or NCSC in the United Kingdom) immediately. For all commercial, nonprofit, and personal domain crises, execute the triage steps below in exact order.

Egin hau orain¶

1. Determine in 30 seconds whether your domain expired, your DNS records were altered, or the domain was transferred to a foreign registrar: Run a live RDAP edo WHOIS query and an authoritative DNS query from a terminal (rdap yourdomain.com edo whois yourdomain.com, eta dig +trace yourdomain.com). Check the Registrar Name, the EPP Status Codes (such as clientHold for billing/verification vs. ok with unfamiliar nameservers), and the Authoritative Nameservers (NS).
2. Freeze all outbound password resets and lock down your Identity Provider (Okta, Microsoft Entra ID, Google Workspace) immediately: If an attacker controls your domain's MX records or NS zerbitzariak, bidalitako mezu elektroniko guztiak jasotzen dituzte *@yourdomain.com. Eskatu berehala zure IT administratzaileei desgaitzeko "Pasahitza ahaztu zait posta elektronikoaren bidez" autozerbitzua berrezartzeko tresna korporatibo guztietan, saio aktiboak baliogabetzeko helbide elektronikoak kanpoko hornitzaileen kontuak berrezartzeko erabil ditzaketen erabiltzaileentzat eta administrazio-saioa aldatzeko hardware FIDO2 segurtasun-giltzetara edo barneko segurtasun-giltzetara. .onmicrosoft.com ordezko domeinuak.
3. ** Gorde RDAP/WHOIS, DNS zonen eta Ziurtagiriaren Gardentasunaren argazki forentse osoak (CT) ezer aldatu baino lehen erregistratzen du**: Gorde erabiltzailearen irteera dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, eta egiaztatu crt.sh/?q=%25.yourdomain.com immediately. Searching crt.sh reveals every unauthorized SSL/TLS certificate the attacker just minted for your subdomains (mail., vpn., login., api.) so you know exactly which internal services they are actively impersonating via Adversary-in-the-Middle (AitM) proxies.
4. Contact the Losing Registrar's dedicated Emergency Abuse / Security Operations Team (not Tier-1 chat support) to trigger an ICANN Unauthorized Transfer Dispute (IRTP) or Registry Lock reversal: If your domain was pushed to another account at the same registrar or transferred via a stolen Auth-Info (EPP) code to a foreign registrar, contact your original registrar's Domain Abuse / High-Risk Security Escalation Desk and request an immediate Registrar Undo / Emergency Transfer Dispute under the ICANN Transfer Policy (Section I.A eta Transfer Dispute Resolution Policy), citing unauthorized credential compromise.
5. Escalate directly to the Top-Level Domain (TLD) Registry Operator if the registrar is unresponsive: Remember the hierarchy: Registrars (like GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) are simply retail resellers; the Registry Operator (such as Verisign for .com/.net, Public Interest Registry (PIR) for .org, Nominet for .uk, CIRA for .ca, DENIC for .de, or auDA for .au) runs the master root zone database. Country-code (ccTLD) registries and several gTLD registries can place an emergency serverHold edo serverUpdateProhibited lock directly at the root level during verified cybercrime incidents.
6. Warn customers, vendors, and banking partners through out-of-band channels that @yourdomain.com email is compromised: If the attacker hijacked your MX records, they will immediately reply to open accounting threads with fake wire transfer instructions. Notify clients via telephone, SMS, LinkedIn, status page on a separate backup domain, or official social media accounts not to trust any email or login portal on the affected domain until restoration is confirmed.

Decision tree: diagnosing and containing a domain or DNS outage¶

Follow this rapid diagnostic flowchart to pinpoint the exact layer of the Domain Name System that has failed or been hijacked:

flowchart TD
    A["Website Down, TLS Certificate Warning, or Corporate Email Halted"] --> B["Run RDAP/WHOIS & dig +trace from External Network"]
    B --> C{"What do RDAP Status & Registrar Fields Show?"}
    C -->|"Status: clientHold, autoRenewPeriod, or redemptionPeriod"| D["Accidental Expiration or ICANN Whois Verification Suspension"]
    D --> E["Log into Registrar Immediately: Pay Renewal / Redemption Fee or Click RAA Verification Link; Request Emergency TTL Flush"]
    C -->|"Registrar Name or Registrant Account Changed Without Authorization"| F["Erregistroko kontu osoa bahitzea edo baimenik gabeko EPP transferentzia"]
    F --> G["Lock Identity Provider (Entra/Google), File Emergency Registrar Abuse Ticket + ICANN Transfer Dispute, Check crt.sh for Rogue Certs"]
    C -->|"Registrar & NS Unchanged, but A / CNAME / MX Records Point to Unknown IPs"| H["Managed DNS Provider Compromise (Cloudflare / Route53 / NS1 API Key or Account Breach)"]
    H --> I["Errebokatu konprometitutako DNS API tokenak, leheneratu eremu ona den fitxategia, ezeztatu Rogue TLS ziurtagiriak, biratu agerian dauden kredentzialak"]
    C -->|"Erregistratzaileak, NS eta Zonako Erregistroak Normala dirudi, baina Guneak huts egiten du SERVFAIL-ekin"| J["Hautsitako DNSSEC konfiantzazko katea (DS erregistroak ez datoz bat edo iraungitako RRSIG)"]
    J --> K["Exekutatu DNSViz.net Egiaztapena: kendu DS erregistro zaharkitua erregistratzailean edo berriro sinatu gunea DNS ostalarian"]

1. fasea: Eraso bektore zehatza identifikatzeko forentse teknikoa¶

When a domain suddenly stops resolving or starts serving a phishing page or cryptocurrency scam, every minute spent guessing wastes precious recovery time. There are four completely distinct scenarios that look identical to an end user in a web browser, and each requires a completely different fix.

How to Read RDAP, WHOIS, eta dig Intzidenteen erantzuna bezalako irteerak¶

Ireki komando-terminal bat Linux, macOS edo Windows-en (WSL edo nslookup) and run the following three diagnostic checks using a neutral public recursive resolver (8.8.8.8 edo 1.1.1.1):

1. Check the Registry-Level Delegation (dig +trace eta RDAP)*:

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Look at the step right after the TLD root servers (for example, a.gtld-servers.net. for .com). Which NS (Nameserver) hostnames are returned by the TLD Registry itself?
   • If the TLD Registry returns your normal nameservers (ns1.yourdnsprovider.com) with status NOERROR, the hijack is happening inside your DNS hosting provider (or it is a DNSSEC breakage).
   • TLD Erregistroak izen-zerbitzari guztiz ezezagunak itzultzen baditu (edo bada whois yourdomain.com berri bat erakusten du Registrar: name and an Updated Date: within the last few hours or days), the hijack happened at the Domain Registrar level.
2. Decode the ICANN EPP Domain Status Codes: Begira Domain Status: lines in your WHOIS edo RDAP output. These standardized Extensible Provisioning Protocol (EPP) codes tell you why a domain is failing or locked:

2. fasea: domeinu maltzurren bahiketa edo baimenik gabeko erregistratzaileen transferentziatik berreskuratzea¶

Erasotzaileek balio handiko domeinu korporatibo, Web3/DeFi, finantza eta komunikabideen domeinuak bahitzen dituzte hiru teknika nagusi erabiliz: 1. Erregistro kontua hartzea (Kredential Stuffing, Infostealer Malware edo SIM Swap): Erasotzaileak zure GoDaddy, Namecheap, Google Domains/Squarespace edo Network Solutions panelean sartzen du saioa, eta itzaltzen da. clientTransferProhibited, aldatzen du NS erregistroak erasotzaileak kontrolatutako Cloudflare kontu batera seinalatzeko, edo bat sortzen du Auth-Info (EPP) code to transfer the domain out. 2. Erregistratzaileen Laguntzaren Gizarte Ingeniaritza: Erasotzaileak faltsututako inkorporazio dokumentuak, gobernu-identifikazio faltsuak edo paperezko gutun-iruzur faltsuak bidaltzen dizkio erregistratzaile baten kontua berreskuratzeko mahaira, jatorrizko IT administratzailea hil dela edo enpresa utzi duela esanez. 3. Azpidomeinua hartzea (Dangling CNAME / Dangling NS): zure domeinu nagusia ukitu gabe dago, baina azpidomeinu zahar bat (promo.yourdomain.com edo status.yourdomain.com) oraindik bat dauka CNAME Duela hilabete ezabatu zenituen AWS S3 ontzi, Azure App Service, GitHub Pages repo, Heroku aplikazio edo Zendesk instantzia deskargatu bat seinalatzen duen erregistroa. Erasotzaileak utzitako hodeiko baliabide-izen hori AWS/Azure/GitHub-en erregistratzen du eta berehala zure azpidomeinu ofizialeko eduki gaiztoa hornitzen du.

1. urratsa: Erasotzailea kanporatu zure hodeiko identitate-hornitzailetik eta posta elektronikoko sistematik¶

Before you even finish filling out the registrar recovery form, assume the attacker is actively reading every email sent to your domain and trying to pivot into your internal cloud infrastructure:

1. Switch Microsoft 365 / Google Workspace to Fallback Domains and Hardware MFA:
   • In Microsoft Entra ID (formerly Azure AD), every tenant has a permanent, un-hijackable fallback domain (yourcompany.onmicrosoft.com). Administrators can log in via admin@yourcompany.onmicrosoft.com even if yourdomain.com DNS is completely hijacked.
   • Disable all SMS, voice call, and alternate-email password reset methods in Entra ID / Okta / Google Workspace (Authentication Methods Policy). Require FIDO2/WebAuthn hardware security keys or number-matching Authenticator push notifications.
2. Audit Outbound and Inbound Email Logs for the Exact Compromise Window:
   • If your MX records were changed at 02:14 UTC, zero legitimate external emails have reached your real mail servers since 02:14 UTC; every single external email sent to your staff during that window was captured in full plaintext by the attacker's rogue mail server (Postfix/Exim listener).
   • Immediately pull a list of every third-party SaaS platform, bank, AWS/GCP root account, GitHub organization, and vendor portal tied to @yourdomain.com email addresses, and check whether the attacker triggered password resets on those external platforms during the hijack window.

Step 2: Execute the Registrar and Registry Emergency Recovery Protocol¶

Do not open a generic "My website isn't working" support chat. You must use the exact regulatory and legal terminology that triggers escalation to the Registrar Tier-3 Security / General Counsel / ICANN Compliance Team:

1. Case A: The Domain Is Still at Your Original Registrar (Account Takeover or Internal "Account Push"):
   • Many attackers do not wait 5 days for an inter-registrar EPP transfer; instead, they use the registrar's instant "Push Domain to Another Account" feature to move your domain into a burner account at the same registrar in 3 seconds.
   • Call and email the registrar's Fraud / Account Hijacking / Abuse Department immediately. State clearly: "URGENT SECURITY INCIDENT: Unauthorized Account Access and Internal Domain Push / DNS Modification of [yourdomain.com]. Requesting immediate freezing of the domain under serverHold/clientUpdateProhibited and rollback of unauthorized DNS/Account changes."
   • Assemble Your Proof of Historical Ownership Packet Right Away: Registrar security teams require incontrovertible proof that you are the legitimate prior registrant before they will pull a domain back from another account. Gather these 5 documents into a single PDF immediately:
     1. Historical Registrar Invoices and Payment Proofs: PDF receipts and credit card / bank wire statements showing your organization paying for the registration and renewal of yourdomain.com over the past 1 to 10 years (including the last 4 digits of the payment card or wire reference).
     2. Government-Issued Corporate Registration & Officer ID: Official Certificate of Incorporation / Articles of Organization matching the historical WHOIS Registrant Organization, plus a government photo ID of the corporate officer signing the affidavit.
     3. Historical DNS Zone File & Server Ownership Proof: Copies of your prior DNS zone file, historical WHOIS snapshots, or proof that your organization owns the autonomous system (ASN) or IP blocks (A records) that the domain pointed to for years prior to today's change.
     4. Original Account Creation Email / Ticket History: Headers of emails received from the registrar at the time the domain was originally registered or renewed.
     5. Official Law Enforcement Report Number: A filed FBI IC3 (ic3.gov) complaint number (United States), Action Fraud reference number (United Kingdom), or national police cybercrime report number. Registrars act dramatically faster when handed a formal law enforcement case number confirming a criminal computer intrusion under 18 U.S.C. § 1030 (CFAA) or the UK Computer Misuse Act 1990.
2. Case B: The Domain Was Transferred Out to a Different Registrar (Inter-Registrar Hijack):
   • Under the ICANN Transfer Policy (formerly IRTP), an inter-registrar transfer requires an Auth-Info (EPP) code and must be blocked for 60 days after certain registrant changes unless waived. If an attacker hacked your account at Registrar A (the "Losing Registrar") and transferred the domain to Registrar B (the "Gaining Registrar"):
   • Contact BOTH the Losing Registrar and the Gaining Registrar immediately, but prioritize the Losing Registrar's Transfer Dispute / Security Team. Under ICANN's Transfer Dispute Resolution Policy (TDRP), the Losing Registrar is the entity that has your historical billing records and login logs proving the transfer was unauthorized. The Losing Registrar can formally contact the Gaining Registrar's compliance officer to execute a cooperative Registrar Transfer Undo, or file a formal TDRP proceeding.
   • Simultaneously send your ownership proof packet and police report to the Gaining Registrar's Abuse Desk demanding that they place an immediate clientTransferProhibited eta clientUpdateProhibited lock on the domain so the attacker cannot hop the domain through a chain of three more offshore registrars ("registrar hopping").
3. File an Emergency Escalation with ICANN (for gTLDs like .com, .net, .org, .io if gTLD) or the ccTLD Registry:
   • If a registrar refuses to investigate an unauthorized transfer or fails to respond during an active hijack, submit an urgent Unauthorized Transfer / Domain Hijacking Complaint via the ICANN Contractual Compliance Portal (icann.org/compliance/complaint).
   • If your domain uses a Country-Code Top-Level Domain (ccTLD), such as .uk, .ca, .au, .de, .fr, .nl, .ch, edo .jp, you have an even faster option: ccTLD registries are governed by national oversight authorities rather than ICANN and almost always maintain direct Registry Emergency Security Teams (for example, Nominet in the UK at 0330 236 9470, CIRA in Canada, DENIC in Germany, AFNIC in France) that can freeze a hijacked domain directly at the national registry level within hours upon verifying corporate identity.

Phase 3: Rescuing an expired domain (clientHold, RedemptionPeriod, eta PendingDelete)¶

Not every sudden global outage is a cyberattack. Every single day, major companies, SaaS startups, and government contractors go completely dark because the credit card on file at their domain registrar expired, and the renewal reminder emails were sent to former-founder@company.com who left the firm three years ago.

Understanding the ICANN Expired Domain Lifecycle Timeline¶

For generic Top-Level Domains (.com, .net, .org, .biz, .info), the ICANN Expired Registration Recovery Policy (ERRP) enforces a strict multi-stage lifecycle after the expiration date passes:

1. Stage 1: Auto-Renew Grace Period (Days 1 to ~30/45 after Expiration):
   • Immediately after expiration (often within 24 to 72 hours), the registrar changes the domain's NS records to a Parked / Expired Renewal Splash Page or places the domain on clientHold.
   • Impact: Your website and corporate email stop working immediately (DNS_PROBE_FINISHED_NXDOMAIN or parking ads).
   • Recovery: Log into the registrar account and pay the standard 1-year renewal fee ($10 to $30 USD). The registrar immediately restores your original NS records.
2. Stage 2: Redemption Grace Period (redemptionPeriod, 30 Days Duration):
   • If no one renews the domain during Stage 1 (usually after day 30 to 42 depending on the registrar's Terms of Service), the registrar deletes the domain at the Registry, and the Registry places it into the mandatory 30-day redemptionPeriod (unless the registrar auctioned the expired domain via an internal expired-domain auction platform like GoDaddy Auctions or NameJet, check your registrar's exact day-30 auction cutoff immediately).
   • Recovery: You can still rescue the domain with 100 percent certainty during redemptionPeriod, only through the original Losing Registrar. You must contact their billing/support desk and pay the Registry Redemption Restore Fee (typically $80 to $250 USD) plus a 1-year renewal.
3. Stage 3: Pending Delete (pendingDelete, Final 5 Calendar Days):
   • Once the 30-day redemptionPeriod expires, the domain enters pendingDelete for exactly 5 days (120 hours).
   • Impact: During pendingDelete, the Registry rejects all standard EPP restore commands from the registrar. At the end of day 5 (for .com/.net Verisign drops, between 18:00 and 19:15 UTC), the domain is released to the public and snatched within 10 milliseconds by automated drop-catching networks.
   • Emergency Action if Caught in pendingDelete or Registrar Expired Auction:
     • If the domain was sold via the registrar's day-30 expired auction before entering Registry redemptionPeriod, check if your registrar offers a short post-auction redemption window or contact the winning bidder/broker immediately.
     • If the domain is truly in the 5-day Registry pendingDelete phase, simultaneously place high-tier backorders across all three major drop-catching networks (DropCatch.com, SnapNames.com, eta NameJet.com) so that if the domain drops to the public pool on Day 5, your backorder captures it or enters you into the closed bidder auction to buy your domain back.

Why Does My Website Still Fail for Hours After I Renewed an Expired Domain? (Fixing Negative DNS Caching)¶

When your domain expires, the registrar replaces your NS records with temporary parking nameservers that often carry a 24-hour to 48-hour TTL (Time-To-Live) (86400 edo 172800 seconds). Even after you pay the renewal bill and your registrar restores your real NS records in the root zone within 5 minutes, public recursive DNS resolvers around the world (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, and ISP resolvers) may keep serving the cached expired parking page until that 48-hour TTL expires.

How to Force an Instant Global DNS Cache Flush in 60 Seconds: Do not wait 48 hours for recursive caches to expire naturally. Manually flush your domain from the three largest global public DNS providers right now using their free web cache-purge portals: 1. Flush Google Public DNS (8.8.8.8 / 8.8.4.4): Visit developers.google.com/speed/public-dns/cache, type yourdomain.com, hautatu erregistro mota NS (and then repeat for A,AAAA,MX, and DS), and click Flush Cache. This clears your domain across every Google DNS data center worldwide in less than 10 seconds. 2. Flush Cloudflare Public DNS (1.1.1.1 / 1.0.0.1): Visit one.one.one.one/purge-cache/, enter yourdomain.com, select NS,A,AAAA, and MX, and click Purge Cache. 3. Flush OpenDNS / Cisco Umbrella (208.67.222.222): Visit cachecheck.opendns.com, enter yourdomain.com, check the results across global nodes, and click Refresh the Cache at the bottom of the table.

Phase 4: Fixing broken DNSSEC (SERVFAIL) after a migration or hijack¶

Domain Name System Security Extensions (DNSSEC) cryptographically signs your DNS records (RRSIG records signed by a Zone Signing Key ZSK and Key Signing Key KSK) and publishes a matching Delegation Signer (DS) hash in the parent TLD zone at your registrar.

While DNSSEC prevents cache poisoning, a broken DNSSEC configuration causes an instant, total global outage (SERVFAIL) on every validating resolver (including 8.8.8.8, 1.1.1.1, Comcast, and major mobile carriers). This most commonly happens during an emergency migration: an administrator moves yourdomain.com's nameservers from Cloudflare to AWS Route 53 (or vice versa) without first deleting the old provider's DS erregistroa domeinu erregistratzailean.

DNSSEC bat diagnostikatzea eta konpontzea SERVFAIL Blokeoa 5 minututan¶

1. Berretsi DNSSEC dela erruduna: Korrika bi dig komandoak bizkarrean: kontsulta normal bat eta ** batekin+cd (Egiaztapena desgaituta)** bandera, ebatzaile errekurtsiboari DNSSEC baliozkotze kriptografikoa alde batera uzteko esaten diona:

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

   • Lehenengo komandoak -rekin huts egiten badustatus: SERVFAIL eta zero erantzunak, bigarren komandoa (+cd) berehala lortzen du -rekinstatus: NOERROR eta zure itzultzen du A grabatu IP helbidea, zure etenaldiaren ehuneko 100 hautsitako DNSSEC konfiantzazko kate bat da.
2. Apurketa zehatza ikuskatu honekin DNSViz.net edo Verisign DNSSEC Debugger:
   • Ireki dnsviz.net edo dnssec-debugger.verisignlabs.com eta sartu yourdomain.com.
   • Diagrama bisual bat marraztuko du ala ez erakutsiz DS zure erregistratzailean argitaratutako erregistroa ez dator bat DNSKEY zure uneko DNS ostalariak zerbitzatzen duen edo zure zonako sinadurak (RRSIG) iraungi dira.
3. Larrialdietarako konponketa:
   • DNS hornitzaileak aldatu berri badituzu: hasi saioa zure Domeinu-erregistratzailean, joan DNSSEC / DS Erregistroak atalera eta ezabatu zaharkitua. DS grabatu (edo ordezkatu berriarekin DS zure DNS ostalari berriak sortutako erregistroa).
   • ** Garbitu DS grabatu cachea**: berehala bisitatu Google Public DNS Cache Pursh (developers.google.com/speed/public-dns/cache) eta Cloudflare Purge Cache (one.one.one.one/purge-cache/) eta garbitu DS eta DNSKEY erregistro motak yourdomain.com beraz, baliozkotze-ebazleek ezabatuak egiaztatzeari uzten diote DS hash berehala.

5. Fasea: Berreskuratu ondorengo garbiketa, TLS ziurtagiria baliogabetzea eta gogortzea¶

Zure domeinu-erregistratzailearen kontua eta DNS erregistroak zure kontrolpean berreskuratzea borrokaren erdia baino ez da. Erasotzaileak zure domeinuko DNS kontrolatzen zuen orduetan edo egunetan, "Domeinu-kontrolaren baliozkotzea" frogatzeko eskumen osoa zuten (DCV) Autoritate Ziurtagiri guztiei (CA) planetan.

1. Ikuskaritza Ziurtagirien Gardentasun Erregistroak (crt.sh) eta Errebokatu Rogue TLS ziurtagiriak¶

Erasotzaile batek zure apuntatzen duenean A edo NS erregistroak zerbitzariari, berehala exekutatzen dira certbot (Let's Encrypt, ZeroSSL, Google Trust Services edo Sectigo) baliozko eta arakatzailean fidagarriak diren TLS ziurtagiriak sortzeko yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, eta mail.yourdomain.com. Even after you restore your DNS records, the attacker still holds the valid Private Key (.key) and signed Public Certificate (.crt) for your domain, which they can use to stage captive-portal Wi-Fi attacks, BGP hijacks, or internal network spoofing for the next 90 days.

1. Query Certificate Transparency Logs:
   • Joan crt.sh/?q=%25.yourdomain.com or Censys Certificate Search (search.censys.io/certificates).
   • Sort by Logged At / Not Before date and inspect every single certificate issued during the hijack window (and in the 24 hours after recovery, due to cached DCV authorizations).
2. Force Immediate Certificate Revocation:
   • Identify the issuing Certificate Authority (Issuer Name) on every unauthorized certificate.
   • Every publicly trusted CA is required under the CA/Browser Forum Baseline Requirements (Section 4.9.1.1) to revoke a fraudulent or unauthorized certificate within 24 hours of confirming that the applicant was not authorized by the true domain owner.
   • If you already regained DNS control over the domain, you can revoke unauthorized Let's Encrypt or ACME certificates yourself in 60 seconds without even needing the attacker's private key: simply install certbot on a server you control, pass a fresh DNS-01 or HTTP-01 challenge for the exact same domain name using a brand-new ACME account key, and run:

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

   • Alternatively, submit the Certificate Serial Numbers directly to the CA's emergency revocation portal (for example, Let's Encrypt's revocation instruction page, DigiCert's /revoke portal, or Sectigo's SSL Abuse reporting form).

2. Lock Down Your Domain Permanently So It Can Never Be Hijacked Again¶

Once operations are restored, implement these five enterprise domain-hardening controls:

1. Enable Registry Lock (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited)*:
   • For mission-critical production domains, upgrade to a registrar that offers true Registry Lock (supported by Verisign on .com/.net, PIR aktibatuta .org, eta MarkMonitor, CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock mailak bezalako enpresen erregistratzaileen bidez eskaintzen da). Erregistroaren blokeoa aktibo dagoela, hacker batek zure erregistratzailearen saioa eta MFA lapurtzen baditu ere, TLD Erregistroak guztiak baztertzen ditu. NS edo transferitzeko aldaketak giza segurtasuneko arduradun batek bandaz kanpoko zeremonia kriptografiko/telefonikoa osatzen ez badu.
2. Argitaratu CAA (Ziurtagiri-agintaritzaren baimena) DNS erregistroak:
   • Gehitu a CAA erregistroa (RFC 8659) to your DNS zone specifying the exact Certificate Authorities allowed to issue TLS certificates for your domain (for example, 0 issue "letsencrypt.org" edo 0 issue "digicert.com", gehi 0 iodef "mailto:security@yourdomain.com"). While an attacker who controls your whole DNS zone can delete a CAA erregistroa, a CAA record stops BGP hijackers or compromised subdomain CNAME targets from using unauthorized CAs.
3. Separate Your Domain Registrar from Your Daily DNS Hosting Provider:
   • Keep your domain registration locked inside a high-security vault registrar account that only 2 corporate officers can access using FIDO2 hardware security keys (YubiKey), and delegate daily DNS record management (A, CNAME, TXT) to a separate managed DNS service with granular Role-Based Access Control (RBAC) and scoped API tokens.
4. Audit and Eliminate Dangling Subdomain CNAME eta NS Records:
   • Run a monthly automated scan of your entire DNS zone file (subzy, nuclei -t takeovers/, or OWASP Amass) to identify any CNAME, ALIAS, or subdomain NS record pointing to an unregistered external cloud resource or expired domain, and delete the DNS record before decommissioning the cloud server.
5. Set Up Automated External RDAP, DNS, and CT Log Monitoring:
   • Configure an external monitor (such as CertSpotter, Cloudflare Certificate Transparency Monitoring, or a simple hourly cron script checking dig NS eta whois) that alerts a dedicated Slack/PagerDuty channel and an off-domain SMS/email address the exact minute a new TLS certificate is logged in Certificate Transparency or an NS/MX/DS record changes.

Maiz egiten diren galderak¶

Iturriak egiaztatu¶

• Cybersecurity and Infrastructure Security Agency (CISA, United States): Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering (CISA mandates on Registry Lock, MFA for DNS/Registrars, Certificate Transparency log auditing, and DNSSEC validation) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Transfer Policy (Inter-Registrar Transfer Policy / IRTP), Transfer Dispute Resolution Policy (TDRP), Expired Registration Recovery Policy (ERRP), and EPP Status Codes Reference (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• National Institute of Standards and Technology (NIST, United States): Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide (csrc.nist.gov).
• National Cyber Security Centre (NCSC, United Kingdom): Protecting Bulk Personal Data and Domain Security: Registry Lock, CAA Records, and Subdomain Takeover Prevention (ncsc.gov.uk).
• CA/Browser Forum (International): Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (Section 4.9.1.1: 24-Hour Mandatory Revocation for Domain Compromise) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS Certification Authority Authorization / CAA Resource Record), and RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

Erlazionatutako gidak¶

• Web hosting crisis, migration, and backup restoration
• Phishing eta arriskuan dauden kontuak
• MFA phishing eta aurkariaren erdiko saihesbidea
• Datu-hausteen erantzuna eta pasahitzen ihesak
• Enpresa ransomwarea eta zerbitzariaren urraketa
• SIM trukatzea