The March 2026 breach of the European Commission's AWS infrastructure did not just expose personal data — it handed attackers cryptographic signing keys that let them forge email from official EU domains. As of April 2026, those keys have not been publicly confirmed as rotated.
On March 24, 2026, the European Commission's cybersecurity operations centre detected unauthorized access to AWS accounts hosting the Europa.eu web platform. The threat actor — later attributed by CERT-EU to TeamPCP, a group with ties to the ShinyHunters ecosystem — had been inside the infrastructure since at least March 19, when a poisoned release of the Trivy container security scanner delivered a stolen AWS API key that functioned as a master access credential across multiple Commission cloud accounts.
The headline figure was 350 GB of data stolen, compressed to roughly 91.7 GB. Media coverage focused on personal data: staff email addresses, names, SSO directory entries. What received less attention was a specific category of cryptographic material in the exfiltrated dataset: DKIM signing keys for European Commission mail domains. CERT-EU confirmed these were in the leaked dataset. As of early April 2026, the Commission had not publicly confirmed that all affected keys had been rotated.
A password can be changed in seconds. A DKIM private key that has been exfiltrated continues to be valid until the DNS record for the corresponding public key is explicitly revoked or rotated. Any organisation that does not rapidly cycle its DKIM keys after a breach leaves a signing credential in the hands of attackers indefinitely.
DKIM — DomainKeys Identified Mail — works by attaching a cryptographic signature to outgoing email. The sending mail server signs the message header and body with a private key; the receiving server retrieves the matching public key from a DNS TXT record and verifies the signature. When the signature matches, the message is considered authentic — the email genuinely originated from the declared domain. DMARC policies then allow or reject messages based on whether DKIM (or SPF) passes.
With a valid DKIM private key for ec.europa.eu or any of the 71 Europa web hosting clients covered by the breach, an attacker can craft a message, sign it with the stolen key, and deliver it to any recipient whose mail server performs DKIM validation. The receiving server sees a valid signature. The message passes DKIM. If the sender domain has a DMARC policy of p=quarantine or even p=reject, the message still passes — because the DKIM signature is cryptographically correct. The filter was designed to stop forgers. It has no mechanism to distinguish a legitimate signer from an attacker who possesses the private key.
The practical attack is straightforward. An attacker uses the stolen DKIM private key to sign a message with a From: header of, for example, commissioner@ec.europa.eu or helpdesk@some-eu-agency.europa.eu. The message is delivered via any outbound mail infrastructure — the attacker's own server, a bulletproof hosting provider, or a compromised relay. The receiving mail server performs the standard sequence: SPF lookup (which may fail if the attacker's IP is not in the SPF record), DKIM verification (which passes because the signature is valid), and DMARC evaluation. If the DMARC policy is p=none — which is still common even for institutional domains — the message is delivered regardless of SPF failure. If the DMARC policy enforces p=reject, but DKIM passes and the d= tag in the DKIM signature aligns with the From: domain, the message is still delivered.
The Commission's internal directory was also part of the stolen dataset. An attacker with both the DKIM keys and a full list of EU Commission staff names, email addresses, and roles has everything needed to build a highly targeted spear-phishing campaign: messages that appear to come from specific, named officials, pass email authentication, and reference real organisational context from the leaked data. For DACH enterprises and public-sector organisations that receive correspondence from EU institutions — regulatory notifications, NIS2-related guidance, procurement communications — this is not a theoretical risk.
DKIM validation passing is not, by itself, evidence of a legitimate message — but most mail platforms treat it that way. Detection requires additional signals. First, check whether your mail gateway logs the DKIM selector used in inbound messages. Legitimate EC infrastructure uses a limited, known set of DKIM selectors; messages signed with selectors that do not correspond to the Commission's current published DNS records indicate a replay or offline-signing attack with a rotated-but-cached key.
Second, correlate the envelope sender (the Return-Path or MAIL FROM address) with the From: header. Legitimate EU Commission mail will have an envelope sender on Commission-controlled infrastructure. An attacker using stolen keys will likely send from a different IP range and a different envelope domain; DMARC alignment checks From: domain against the domain in the DKIM d= tag, but a sophisticated attacker using a subdomain or a cousin domain to pass SPF while using the leaked DKIM key for the primary domain can create alignment ambiguity that automated filters miss.
Third, look at message routing. EU Commission mail routes through Commission-managed MTAs. Check the Received: headers in suspected messages: the hop immediately before your gateway should be a known EC mail relay. Anomalous routing through unrelated ASNs is a reliable signal.
If your organisation regularly exchanges email with EU institutions, the immediate actions are: enable DMARC reporting (rua= tag) on your own domain if not already active, so you can see whether your domain is being spoofed in turn; configure your mail gateway to flag or quarantine messages from EU Commission domains where the sending IP does not resolve to Commission-controlled infrastructure, even when DKIM passes; and brief your security team that DKIM-passing email from europa.eu subdomains should not be treated as implicitly trusted until the Commission confirms full key rotation.
The broader lesson is about how breach scope is communicated. Data breach notifications typically focus on personal data because that triggers GDPR reporting obligations. Cryptographic material — API keys, DKIM keys, code-signing certificates — rarely appears in public breach summaries even when it represents the most operationally dangerous component of what was taken. The EU Commission breach is a precise example: 350 GB of leaked data generated substantial coverage, but the DKIM key exposure, which creates a persistent and difficult-to-detect phishing capability, was noted in technical analyses and largely absent from executive summaries.
Organisations managing their own external exposure — including mail infrastructure, publicly accessible credentials, and domain signing material — benefit from continuous visibility into what key material and configurations are reachable from the internet. Tinte.io's attack surface platform includes mail infrastructure checks as part of its external asset inventory. If you want to understand what signing and credential material your domains expose, that is a reasonable starting point for a review.
Get a comprehensive threat briefing for your organization — exposures, breached credentials, and actionable recommendations.
CISA added CVE-2026-33634 to KEV on March 26 after active exploitation evidence. Teams using Trivy in CI/CD should treat this as an immediate exposure review.
Phishing remains the #1 initial access vector. Understanding how these attacks work is the first step to building resilience.
A PhaaS platform called EvilTokens has enabled a campaign that compromised 340+ Microsoft 365 organizations across five countries, including Germany, by exploiting a legitimate OAuth authentication flow that bypasses MFA entirely.
Most organizations don't know what attackers can see. External Attack Surface Management closes this gap — before threat actors exploit it.