Google meldt dat aanvallers drie landendomeinen op ccTLD-niveau hebben gehijackt om valse Google certificaten te verkrijgen. Het gaat om domeinen die eindigen op .gh (Ghana), .sl (Sierra Leone) en .as (American Samoa). Met zo’n certificaat kan een aanvaller zich tijdens een versleutelde verbinding voordoen als de echte site, waardoor gevoelige gegevens die via HTTPS worden verstuurd, kunnen worden afgelezen.
Volgens Google zijn de eigen systemen niet gecompromitteerd. De risico’s zijn echter wel reëel voor elk domein dat onder de getroffen ccTLD’s valt. Chrome heeft de ongeautoriseerde certificaten voor Google-domeinen geblokkeerd via CRLSets, en Google werkt samen met certificaatautoriteiten om certificaten te laten intrekken.
Wat er volgens Google is gebeurd
De kern van het incident draait om het misbruiken van DNS-controle. Een certificaat komt tot stand wanneer de aanvrager aantoont dat hij controle heeft over het betreffende domein, bijvoorbeeld door een DNS-record aan te passen. Bij deze campagne zouden de aanvallers tijdens de kaap een deel van de autoritatieve DNS-records hebben veranderd, waardoor certificaatuitgifte mogelijk werd.
Google zegt daarbij geen aanwijzingen te hebben dat certificaatautoriteiten zelf iets fout hebben gedaan. Het probleem zat dus in het feit dat er aantoonbaar domeincontrole werd gepresenteerd terwijl die controle door de aanvallers werd afgedwongen.
Waar je de signalen terugvindt: Certificate Transparency
Certificate Transparency (CT) logt publiek welke certificaten door certificaatautoriteiten zijn uitgegeven. Met behulp van CT-zoekdiensten vonden onderzoekers op 7 oktober de certificaten die onder de drie ccTLD’s waren afgegeven. Google geeft aan dat er tussen 22 en 27 september minstens twaalf certificaten zijn uitgegeven voor namen gerelateerd aan Google en YouTube onder .gh, .sl en .as, waaronder combinaties als google.com.gh, google.sl en google.as.
Het totaal kan volgens Google hoger liggen, omdat niet alle mogelijke namen werden doorzocht. Ook wijst Google op CT-data die duidt op betrokkenheid van andere organisaties, waaronder bekende wereldwijde merken en veelgebruikte online diensten, zonder daarbij namen te noemen.
Chrome-blokkades en intrekkingen: wat betekent dat voor gebruikers?
Google stelt dat Chrome de ongeautoriseerde certificaten voor Google-domeinen heeft geblokkeerd. Dat doet de browser via CRLSets: een mechanisme om certificaten snel in noodsituaties te blokkeren. Daarnaast zijn certificaten ingetrokken, zodat apps en browsers die niet afhankelijk zijn van Chrome ook beschermd kunnen worden.
Voor Chrome-gebruikers hoeft er volgens Google niets te worden gedaan. Domeinbeheerders moeten daarentegen juist niet volledig leunen op browsermaatregelen. Google onderstreept dat analyses en blokkades niet automatisch garanderen dat elk getroffen domein in elke context onmiddellijk wordt beschermd, zeker niet in andere browsers of apps.
Welke certificaten zijn gezien en wie gaf ze uit?
CT-logonderzoek laat zien dat de certificaten domain-validated waren: ze zijn uitgegeven na een controle die aan de autoriteit moest aantonen dat de aanvrager het domein controleert. Voor de onderzochte gevallen geldt bovendien dat in de bekeken records meerdere certificaten afkomstig waren van Google Trust Services, de eigen certificaatautoriteit van Google.
Van de twaalf certificaten werden er elf door Let’s Encrypt uitgegeven en één door ZeroSSL. Google en de betrokken partijen hebben daarnaast aangegeven dat deze certificaten zijn ingetrokken.
Timing: van uitgifte naar intrekking
Google vermeldt geen exacte datums voor wanneer de DNS-kaap plaatsvond, maar CT-data maakt de volgorde wel zichtbaar. De certificaten werden gelogd in drie batches, telkens één ccTLD tegelijk: .gh op 22 september, .sl op 25 september en .as op 27 september.
Ook de intrekking volgde niet overal exact op hetzelfde moment. Cert Spotter liet zien dat alle certificaten in de periode erna als ingetrokken stonden. De kortste tijd tussen eerste logging en intrekking was ongeveer anderhalve dag, de langste bijna een week.
Wat domeinbeheerders nu kunnen doen
Volgens Google moeten domeinbeheerders twee hoofdzaken combineren: zichtbaarheid (weten wanneer er certificaten voor je domein worden uitgegeven) en preventie (beperken welke certificaatautoriteiten nog mogen uitgeven).
1) Monitor CT-logs voor elk domein
Google adviseert om CT-monitoring in te zetten voor elk domein dat je beheert, inclusief geparkeerde domeinen en varianten onder ccTLD’s. CT-monitoringdiensten kunnen een melding sturen wanneer er een certificaat wordt uitgegeven voor een domein.
Let daarbij extra op wanneer er geen aanvraag is gedaan: valse Google certificaten of certificaten voor andere namen zijn precies het soort afwijking dat CT-alerts zichtbaar kan maken.
2) Zet een streng CAA-record
Een CAA-record (Certification Authority Authorization) is een DNS-record waarin je vastlegt welke certificaatautoriteiten voor jouw domein certificaten mogen uitgeven. Google raadt aan om de record zo strikt mogelijk te maken en te koppelen aan je eigen account bij de CA, mits die optie wordt ondersteund.
Belangrijk nuancepunt: een CAA-record kan geen certificaat tegenhouden als een DNS-kaping op dat moment nog actief is en een aanvaller de record kan verwijderen of aanpassen. Zodra je DNS weer onder controle hebt, helpt een strikte CAA-record wél om herhaling te beperken, omdat de CA dan niet kan uitgeven tegen je eigen regels in.
3) Meld certificaten die je niet hebt aangevraagd
Als je een certificaat ziet dat je niet hebt geïnitieerd, meld het aan de CA die het certificaat heeft uitgegeven. Volgens de Baseline Requirements kunnen partijen een Certificate Problem Report indienen, en een CA moet die binnen 24 uur onderzoeken en de eerste bevindingen rapporteren.
Waarom DNS-kaap zo lastig te stoppen is
Deze casus laat zien hoe complex echte aanvallen op certificaatuitgifte kunnen zijn. Een certificaat is op zichzelf een “vertrouwensanker”, maar het proces ernaartoe leunt op een controlemechanisme: het aantonen van domeincontrole. Als een aanvaller de juiste DNS-records weet te wijzigen binnen de periode dat de controle wordt uitgevoerd, kan hij alsnog certificaten laten uitgeven.
Daarom werken defensies het best in lagen: CT-monitoring om vroegtijdig te zien wat er is uitgegeven, intrekking en browserblokkades om schade te beperken, en CAA om uitgiftevoorwaarden te verstrengen.
Praktische lessen voor security teams
Als je organisatie domeinen beheert, kijk dan verder dan alleen “wel/niet HTTPS”. Richt processen in die certificaten signaleren voordat iemand ze misbruikt. Dat betekent: zorgen dat CT-monitoring een alarm oplevert bij onbekende uitgifte, dat DNS-wijzigingen traceerbaar zijn en dat je weet wie CAA-records kan aanpassen.
Heb je daarnaast te maken met domeinen of services die gevoelig zijn voor man-in-the-middle scenario’s, koppel je beleid aan incidentrespons. Denk ook aan het beperken van misconfiguraties en het tijdig patchen van gerelateerde componenten.
Wil je nog breder kijken naar hoe aanvallers DNS- en certificate-achtige misleidingen kunnen combineren, dan kan dit artikel over het herkennen van social engineering in live gesprekken ook nuttig zijn als aanvulling op je technische controles: Social engineering herkennen in live gesprekken.
Conclusie
De melding van Google laat zien dat valse Google certificaten kunnen ontstaan wanneer aanvallers ccTLD-registries en bijbehorende DNS-controle misbruiken. Hoewel Chrome de ongeautoriseerde certificaten heeft geblokkeerd en certificaten zijn ingetrokken, blijft het belangrijk dat domeinbeheerders zelf handelen: monitor CT-logs, zet een streng CAA-record en rapporteer verdachte certificaten.
Door die maatregelen te combineren, verklein je de kans dat een versleutelde verbinding wordt misbruikt als vermomming—en ontdek je sneller wanneer er iets is uitgegeven dat niet van jouw organisatie komt.
Bron: https://thehackernews.com/2026/10/attackers-hijack-gh-sl-and-as.html
