Domain Hijacking via Country Registries: Lessons from .gh, .sl and .as, a CAA Scan of 330 Egyptian Domains and a Protection Checklist

Short answer: Between 22 and 27 September 2026, attackers compromised the registries of Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as), changed DNS records for selected domains, and obtained genuine HTTPS certificates for Google, YouTube and other global brands. The lesson for Egyptian companies: domain hijacking can start outside your company and outside your hosting provider, and the practical defenses are a CAA record bound to your own certificate authority account, Certificate Transparency (CT) monitoring, and a locked-down registrar account. We scanned 330 Egyptian domains on 29 October 2026: only 12 (3.6%) publish a CAA record, and none binds it to a specific account.

Domain hijacking is when an unauthorized party takes control of a domain's DNS records, whether through the registrar account, the DNS provider or the top-level registry itself, and points visitors, email and certificate checks to its own servers. What made the September 2026 incidents different is that the breach happened at the country registry level, so every domain ending in .gh, .sl or .as was at risk no matter how well its owner protected it, and the attackers obtained trusted certificates that let browsers open fake sites normally, with no warning.

What happened in the .gh, .sl and .as registries?

Chrome's security team said in a Google blog post on 6 October 2026 that Google's own systems were not breached; instead, attackers compromised the three registries, modified authoritative DNS records and obtained unauthorized HTTPS certificates. Google said it had no reason to believe the certificate authorities did anything wrong, because the attacker passed the domain control check "correctly" once it controlled DNS.

According to The Hacker News, which reviewed CT logs, at least 12 certificates were issued for seven Google and YouTube domains: 11 by Let's Encrypt and one by ZeroSSL, all revoked by 1 October.

Notably, all seven Google domains carried a strict CAA record allowing only Google Trust Services to issue, yet certificates came from other CAs, because whoever controls DNS during a hijack can remove or replace the CAA record.

Why domain hijacking matters to Egyptian companies

There is no indication that the Egyptian .eg registry suffered a similar incident. But the case shows that your domain's security depends on a chain you do not fully own: the country registry, the registrar, the DNS provider and your own account. Several factors bring the lesson closer to home:

• .eg is still not DNSSEC-signed; on 29 October 2026 we confirmed there is no DS record for it in the DNS root, as explained in our .eg DNS protection guide.
• Many companies hold other countries' domains for branches or campaigns, and Google itself advises that monitoring should cover "parked or regional ccTLD properties".
• A rogue certificate means an impersonating site looks fully secure, so a customer may enter login or payment details without any warning.

What is a CAA record, and what can't it do?

A CAA record is a DNS record that lists the certificate authorities allowed to issue certificates for your domain, and every CA must check it before each issuance under RFC 8659. A CAA record cannot stop issuance during an active DNS hijack, but it closes the door once you regain control.

The reason is that CAs may reuse a completed domain control check for a while: up to 200 days today under the Baseline Requirements, falling to 100 days in March 2027 and 10 days in March 2029, while Let's Encrypt reuses it for 30 days. An attacker who passed the check during a hijack could request new certificates after it ends, unless your CAA record restricts issuance to your own account.

The accounturi and validationmethods parameters

RFC 8657 adds two CAA parameters: accounturi limits issuance to a specific ACME account, and validationmethods limits the accepted validation methods, such as dns-01 or http-01. The Let's Encrypt documentation explains that accounturi ensures someone who temporarily hijacks your domain but lacks your account key cannot issue malicious certificates.

We scanned 330 Egyptian domains: what did we find?

On 29 October 2026, Smart One Group checked every .eg domain in the Tranco top-1M list (list 262N9), 332 domains in total, of which 330 resolved. We queried CAA records while climbing the domain tree as the standard requires, along with name servers and the issuer of the certificate actually served on port 443.

Results by domain type

• .gov.eg: only 1 of 86 government domains publishes CAA.
• .edu.eg: none of 91 education domains publishes CAA.
• .com.eg: 9 of 90 commercial domains (10%), the best-performing group.
• Second-level names directly under .eg: 2 of 47.

Technical notes from the scan

• Four domains carry the same five-CA list (one adds a sixth CA), resembling the sets CDN platforms add automatically, allowing several CAs without a deliberate choice.
• One domain has only an issuewild tag and no issue tag; under the standard, issuewild is ignored for non-wildcard certificates, so their issuance stays unrestricted.
• 60 of 272 delegated domains (22%) use name servers that all sit under .eg, so both the domain and its DNS provider depend on the same registry.
• We found no mismatch between the current certificate issuer and the published CAA list.

An 8-step protection checklist

1. Inventory your domains: list every company domain, including campaign, foreign-branch and parked domains, and who controls the registrar account for each.
2. Secure the registrar account: enable two-factor authentication and transfer lock, and make sure the account belongs to the company, not an employee, as covered in our company domain ownership guide.
3. Publish a restrictive CAA record: allow only the CA that actually issues your certificates, and add issuewild if you use a wildcard certificate.
4. Bind the record to your account: if your CA supports accounturi, as Let's Encrypt does, bind the record to your account ID and specify the validation method.
5. Add iodef: an address that receives reports of violating issuance requests, where CAs support it.
6. Monitor Certificate Transparency: set up alerts with services such as Cert Spotter or crt.sh for all your domains, so you know as soon as a certificate you did not request appears.
7. Have a response plan: if you find a certificate you did not request, file a Certificate Problem Report with the issuing CA, which must investigate and report initial findings within 24 hours.
8. Automate certificate renewal: certificate lifetimes are getting shorter, and automation reduces errors, as described in our SSL certificate validity guide.

How Smart One Group can help

Our team reviews your DNS and CAA records, configures account binding with your CA and sets up certificate monitoring as part of our domain management, hosting and support contract services. If you would like a free initial check of your company's domains, get in touch.

Frequently asked questions

Was Egypt's .eg affected by the September 2026 incidents?

No. The disclosed incidents involved only the .gh, .sl and .as registries, and no party has reported any impact on .eg. The case does show that risk can come from a country registry itself, so every company needs its own layers of protection.

Does a CAA record prevent domain hijacking?

No. A CAA record does not stop the hijack itself, because an attacker who controls DNS can delete it. Its value is that it blocks unauthorized CAs and prevents an attacker from reusing an earlier check to obtain new certificates after you regain control, especially when bound to your account with accounturi.

What is Certificate Transparency (CT)?

Certificate Transparency is a set of public logs that record every HTTPS certificate trusted by browsers. Monitoring them gives you a near real-time alert when any certificate is issued for your domain, and that is how other organizations hit by the same attacks were identified.

How do I check whether my domain has a CAA record?

Use the dig command with the CAA record type, or any online DNS lookup tool. If no result appears for your domain or any parent domain, any publicly trusted CA may issue a certificate for it.

Does CAA conflict with Cloudflare or another CDN?

No, but the list must include the CAs the platform uses to issue your certificates, or renewal will fail. Review the list after any change of provider or certificate type.

What should I do if I find a certificate I did not request?

First check your DNS records and registrar account, then file a Certificate Problem Report with the issuing CA to have it revoked, change passwords, enable two-factor authentication and publish a CAA record bound to your account.