Domain Hijack Recovery: Check Certificates After DNS

Domain hijack recovery continues after DNS is restored. Check Certificate Transparency for unexpected certificates, ask the issuing certificate authority to revoke unauthorized ones, restore restrictive issuance policy, and keep monitoring assigned to an owner. A working website and a browser emergency block each answer only part of the recovery question.

On October 6, Google reported authoritative DNS manipulation affecting the .gh, .sl and .as namespaces, followed by unauthorized certificates for Google and other organizations. Google says its own systems were not compromised and gives no reason to blame the issuing certificate authorities. Chrome blocked certificates through CRLSets while Google also coordinated revocation with issuers. This is Google’s account of the incident, not a complete public reconstruction of its impact. Google’s incident report.

What remains after DNS is restored?

Restoring DNS control does not invalidate an existing certificate. Certification Authority Authorization, or CAA, governs which authorities may issue certificates; it does not govern how a client validates an already issued certificate. Changing that policy cannot retroactively cancel issuance. RFC 8659.

Your website can resolve to the right server and serve its normal certificate while a certificate issued during unauthorized control remains unrevoked. Check domain control and certificate status separately.

Start a recovery record with these questions:

The same distinction applies to leaked credential reports: stopping future access and understanding past activity are separate decisions.

Recover control and preserve the investigation window

Work with the relevant registrar, registry and DNS providers to recover control. Preserve the available change records and establish the period you need to investigate before routine cleanup makes the sequence harder to reconstruct.

Write down which layer you believe was affected and which provider confirmed recovery. A compromised registrar account, altered authoritative records and a registry-level incident may involve different organizations. Google’s report concerns authoritative DNS manipulation in three namespaces. Google’s account.

For each affected domain, record the expected delegation, DNS provider and services that depend on it. Include regional domains, redirected names and parked properties. A domain without an active website can still belong in your certificate investigation. Google explicitly recommends monitoring every owned domain, including parked and regional properties, and warns that its investigation may miss affected domains. Google’s owner guidance.

Give the investigation window a reason. If you have an earliest confirmed unauthorized change and a provider-confirmed restoration time, preserve both. If records are incomplete, say which boundary is uncertain. A convenient window around the first alert is a starting point, not proof that earlier activity did not occur.

Find unexpected certificates in Certificate Transparency

Certificate Transparency, or CT, makes certificates and precertificates visible in public, append-only logs. Monitors inspect logs and can notify subscribers about entries they find. CT gives you issuance evidence to investigate; a log entry does not prove interception or data theft. How CT works.

Search for the affected domain in crt.sh, a CT lookup linked from Let’s Encrypt’s revocation instructions. Open relevant results and inspect the covered names, issuer, validity dates and log timestamps against your investigation window. Use the certificate and logging details together rather than treating a validity start date as an exact issuance timestamp.

Compare those results with deployment and renewal records. Ask the service owner whether each certificate belongs to an ordinary renewal, a CDN or another authorized deployment. Download unexplained certificates when available so the issuer can investigate the same artifact.

For every unexplained result, preserve a compact evidence record:

• The domain names covered by the certificate, including its subject alternative names.
• Issuer, serial number and certificate fingerprint.
• Validity dates and the relevant log reference.
• Whether the observed entry is a certificate or a precertificate.
• The deployment or renewal records you compared it with.
• The person who reviewed it and the conclusion they reached.

Keep precertificates distinct. A precertificate supports the CT logging process and is not itself a usable server certificate. A result labeled as a precertificate should remain labeled that way in your escalation and report. Do not turn it into a claim that you observed a certificate being served. CT’s description of precertificates.

CT monitoring has timing and coverage limits. The logging process includes a maximum merge delay, and your monitor sees the logs it checks. Do not promise instantaneous detection or treat a quiet alert feed as a complete investigation. The CT project publishes a monitor directory, but inclusion there is not a guarantee of completeness or a recommendation based on your requirements.

Request revocation from the issuing certificate authority

Escalate unauthorized issuance to the authority that issued the certificate and follow its documented revocation process. DNS restoration, a replacement certificate and an emergency browser block are separate events; none should stand in for the issuer’s response.

Send the identifiers and evidence you gathered, explain why issuance was unauthorized, and retain the request and subsequent replies. If several names appear in one certificate, flag that fact early. You may need issuer assistance rather than assuming that control of one domain is enough for the procedure you intend to use.

Let’s Encrypt documents one useful example: after regaining domain control, an owner can use a different authorized account to request revocation by demonstrating control of all identifiers on the certificate. Possession of the attacker’s private key is therefore not the only authorization route. This is Let’s Encrypt’s procedure; consult the actual issuer’s instructions for your case. Let’s Encrypt revocation documentation.

Track each request until you have a documented outcome. “Sent an email to the CA” is a pending action. An issuer response and certificate status evidence support a stronger statement. Record which certificate the outcome covers so a response about one serial number cannot accidentally close several unexplained entries.

What does a Chrome block establish?

Chrome’s CRLSets support emergency certificate blocking and include a subset of revocations collected from certificate-authority lists. They are not a complete copy of every certificate revocation. Google’s response used Chrome blocking and CA coordination as distinct actions. Chromium’s CRLSet documentation, Google’s incident response.

Google warns that its interventions do not reliably protect non-Chrome users. If you check browser or API-client behavior, record the clients, versions or environments examined, the time and the observed result. Keep that coverage separate from the issuer’s revocation response.

Restore CAA without breaking legitimate renewals

CAA is an issuance control to review after you recover DNS. It cannot prevent unauthorized issuance while an attacker controls the DNS policy itself, and it cannot revoke an existing certificate. Google recommends restoring restrictive CAA with supported account and validation-method bindings to constrain later issuance using cached validation state. Google’s guidance.

Cached validation matters because the end of unauthorized DNS control is not necessarily the end of every issuance opportunity created during that period. Treat the review as a provider-specific configuration task. Do not assume a generic CAA record closes that gap without checking how your issuer supports the relevant restrictions.

RFC 8657 defines two parameters: accounturi, which binds authorization to an account URI, and validationmethods, which limits the validation methods authorized by that record. Their effect depends on explicit support from the named certificate authority. An unsupported assumption about either parameter can leave your intended restriction unenforced. RFC 8657.

Before changing production records, identify your legitimate issuers and production issuance accounts. Confirm the exact account URI with the issuer or the system managing certificates. A human’s login email is not a substitute for that account identifier. Include the renewal path as well as the last manual issuance, because those may be operated by different systems.

Review the policy as a whole:

1. Confirm that each named issuer supports the bindings you plan to use.
2. Check the production account URI and permitted validation methods.
3. Review wildcard authorization separately where it applies.
4. Examine aliases, delegated names and subdomain policy.
5. Inspect every permission record for an unintended alternative authorization.
6. Verify that legitimate issuance and renewal still work with the intended restrictions.

Let’s Encrypt documents support for http-01, dns-01 and tls-alpn-01 method restrictions and ACME account bindings. It checks CAA before each issuance and explains that multiple permission records are additive. Its documentation also describes subdomain overrides and CNAME resolution. Use those details when Let’s Encrypt is your issuer, without assuming every authority has identical behavior. Let’s Encrypt CAA documentation.

The additive rule deserves a deliberate check. A tightly restricted record can coexist with another authorization that permits the issuance you meant to prohibit. Reading only the new record is not enough. Review the effective policy for the names your certificate covers, including any relevant delegation or alias behavior.

Keep the operational test with the configuration change. Record what issued successfully, through which account and method, and which renewal path you verified. Check the renewal path before accepting the change, so the policy does not block your next legitimate certificate.

Keep certificate monitoring assigned across your domain portfolio

Keep monitoring active after immediate recovery, with an owner who can reconcile alerts and reach the issuing authority. Google recommends coverage across all owned domains because a central response may miss affected names. Google’s monitoring recommendation.

Build the monitoring scope from your domain inventory rather than from your active websites. Include regional brands, redirects, parked domains and names delegated to other teams. For each property, retain the expected operator and legitimate issuance path. That makes a new alert answerable even when the original responder is unavailable.

Decide where alerts arrive and what happens when nobody responds. For a small team, a clear primary owner and backup can be more useful than an unread shared inbox. Your response route should let someone preserve the entry, contact the service owner and escalate unexplained issuance without inventing the process during an incident.

Monitoring does not authorize active testing against every destination associated with a domain. If investigation expands into probing a service, check its operator and the permission you hold. Our security scanning scope guide explains why a DNS relationship alone does not establish permission.

Keep recovery evidence with the report

Close the report against explicit outcomes: restored control, reviewed certificate evidence, documented issuer responses, checked issuance policy and assigned remaining work. Name the limits alongside the results so another person can assess the decision without repeating the investigation.

A useful closure note might read: “The provider confirmed control restored for these domains. We reviewed these CT results against deployment records and escalated two unexplained entries to their issuers. Their responses are linked here. We verified the stated CAA policy and renewal path. Our client checks covered these environments; the separate activity review remains assigned to this owner.”

Replace every placeholder with your actual evidence, including pending issuer responses and gaps in the investigation window.

In Kit, a security report can hold a named owner, supporting attachments, internal notes and linked provider or remediation tickets. Its timeline brings together status changes, assignments and correspondence. You can record root cause, corrective actions and remaining lessons in a postmortem. Keep the technical recovery work and its results linked to that record.

That gives your team a place to review the handoff and closure decision. Inspect Kit’s Security workflow, then compare it with your current report process: can the next responder identify the owner, find the certificate evidence and see which recovery claims still need verification?