1. Published both public AND private RSA keys to DNS
In a catastrophic security blunder, aicompass.co.uk published both their BEGIN PUBLIC KEY and BEGIN RSA PRIVATE KEY to the global DNS network. Anyone in the world could query these records and retrieve the private key. The key has been redacted below.
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNA...[REDACTED]
-----END PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQC...[REDACTED FOR SAFETY]
-----END RSA PRIVATE KEY-----
A raw RSA private key was published publicly to DNS. This means any email signed with the corresponding DKIM key could potentially be forged. The key material has been redacted in our display.
A full RSA private key was published in what appears to be a DKIM record field. DKIM records should only ever contain the *public* key. Someone copied from the wrong file. The full private key (2048-bit) was discoverable by anyone running a DNS query.
4. Chunked a massive private key across three TXT records
DNS has a 255-character limit per TXT string, so this admin chunked what appears to be a massive raw base64 private key across three separate TXT records. Three queries, one complete private key. The internet is a fascinating place.
Admiral Group, a FTSE 100 insurance giant, leaked an enterprise LastPass string containing what looks like a master password or shared folder key. The string `lastpass-JBRtp8B#SaQ5t...` was fully readable in global DNS. We've redacted the sensitive portion.
6. DNSSEC key placed in a TXT record, breaking the chain of trust
The `257 3 13` prefix is unmistakable: this is a DNSKEY record (DNSSEC cryptographic signing key using ECDSA Curve P-256). The admin pasted their highly sensitive DNSSEC key directly into an unencrypted TXT record instead of the DNSKEY record type. This completely breaks DNSSEC's chain of trust and exposes the signing key to any DNS observer.
7. Both RSA public and private keys published to DNS
Another catastrophic security failure: baltany.co.uk published both their BEGIN PUBLIC KEY and BEGIN RSA PRIVATE KEY to the global DNS zone. Anyone with a DNS resolver — which is everyone with an internet connection — could query these records and exfiltrate the private key. The private key has been redacted in our display.
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNA...[REDACTED]
-----END PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
[REDACTED FOR SAFETY]
-----END RSA PRIVATE KEY-----
birdandson.co.uk leaked their full RSA private key to the global DNS network. Anyone actively monitoring this zone data — and many automated tools do — can now potentially impersonate or decrypt traffic meant for this domain. The key material has been redacted in our display.
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQC...[REDACTED FOR SAFETY — full 2048-bit private key]
-----END RSA PRIVATE KEY-----
9. RSA private key leaked without the BEGIN/END headers
Multiple large Base64 strings starting with `MIIEvQIBADANBgkqhkiG9w0...` appear in this domain's TXT records. The `MIIE` prefix is the standard ASN.1 DER encoding signature for a PKCS#8 RSA private key. The admin stripped the `-----BEGIN PRIVATE KEY-----` headers — perhaps thinking that removed the sensitive parts — but left the actual key material fully intact and globally readable.
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC...[REDACTED — full RSA private key material]
A complete RSA private key starting with `-----BEGIN RSA PRIVATE KEY-----` was published to DNS. At this point in scanning the .co.uk zone, the pattern is clear: DNS TXT records are being used as accidental key stores by administrators who confuse their zone file with their server's file system. The key material has been redacted in our display.
A raw JSON Web Token (JWT) starting with the telltale `eyJ0eXAiOiJKV1Qi...` was found in the TXT records. Anyone can base64-decode the payload to read internal tenant IDs, expiration dates, and other claims. No secret needed.
Another raw JWT in DNS. Decoding the payload reveals the domain, expiration timestamp (Unix epoch), and internal tenant/organisation identifiers. The algorithm is HS256—meaning the signature can potentially be brute-forced if the secret is weak.