On a Saturday in October 2016, a major Brazilian bank ceased to exist. Not the buildings — the internet version. For about five hours, every one of its domains, all 36 of them, pointed at servers the bank didn’t own. Customers who typed the bank’s address into their browser got a pixel-perfect copy that harvested their credentials and pushed malware dressed up as a security plugin. Online banking, mobile, email, FTP — all of it, redirected.
The attackers never breached the bank. They didn’t need to. Kaspersky’s Dmitry Bestuzhev, who dug into the case, found they’d gotten into the bank’s account at Registro.br, the .br registrar, and simply changed where the domains pointed. Spear-phishing of registrar staff was the suspected way in; a cross-site request forgery bug on the registrar’s own site didn’t help. The bank had spent years hardening its infrastructure. The attackers walked in through the one door it didn’t control.
This keeps happening, and it keeps working, because of a fact most people never think about: your domain registrar sits above everything else you do for security.
The thing above the stack
Think about what you actually protect. You get a TLS certificate so nobody can impersonate you. You turn on DNSSEC so nobody can forge your DNS answers. You put a WAF in front of your origin, rotate your keys, lock down SSH. All of that assumes one thing is true: that the DNS records saying “this domain lives here” are yours.
The registrar is where that assumption lives. It’s the control plane for your domain — the account that decides which nameservers are authoritative, where the A records point, who the domain even belongs to. And here’s the uncomfortable part: it’s usually protected by a username, a password, and a support line staffed by humans who can be talked into things.
So an attacker has a choice. They can attack your carefully engineered crypto — fight your TLS, your DNSSEC, your firewall. Or they can log into the account that makes all of that irrelevant with one form submission. Change the nameservers and your DNSSEC keys go with them. Point the domain at their server and their Let’s Encrypt certificate makes the padlock green in about ninety seconds. The victim’s entire security investment routes around itself.
Attackers are not stupid. They go for the control plane.
When the plane itself is the target
The Brazilian bank was one account. In 2019, Cisco Talos published something worse: a campaign they called Sea Turtle, where the attackers went after the registrars and registries themselves.
Talos tracked at least 40 organizations across 13 countries compromised between roughly January 2017 and early 2019 — mostly national-security and government targets in the Middle East and North Africa. The method was the same idea scaled up: compromise the credentials of accounts that can edit DNS, then rewrite nameserver, A, and MX records to route victims through attacker-controlled machines that could harvest more credentials and mint valid certificates on the way through.
The detail that should bother you is the January 2019 compromise of Netnod, a Swedish DNS operator — described as the first publicly confirmed case of a DNS registry being breached for espionage. Not a customer account at a registry. The registry. When the thing that keeps the master copy of a TLD’s records gets owned, “just enable DNSSEC” starts to sound quaint. The people who could sign the lie were inside the house.
Talos’s own follow-up noted the group kept operating even after being publicly exposed. That tells you the economics work. Owning DNS at the source is expensive to pull off and enormously valuable, so a well-resourced actor keeps paying for it.
Sometimes there’s no hack at all
Here’s the part that annoys me most, because it’s not even technically impressive.
In late 2020, someone took perl.com — the domain for a 30-plus-year-old programming language — by talking Network Solutions into transferring it. Reporting on the incident points to a social-engineering attack backed by forged documents, not a breach of any server. The attacker changed the registrant contact in September, waited out ICANN’s 60-day post-change transfer lock (a rule meant to prevent hijacking, patiently used as a countdown timer), then bounced the domain to BizCN in December and to Key Systems in January. By then it was listed for sale at $190,000 on Afternic. It only came back because journalists started asking questions and the community made noise; the domain was restored to its longtime owner in early February 2021.
No zero-day. No malware. A convincing email and some fake paperwork against a support process. The domain — the identity of an entire language community — moved because a human at a registrar believed a story.
You cannot patch that with a stronger cipher.
The fix almost nobody turns on
There is a real defense, and it’s been sitting in the protocol the whole time.
Every domain has EPP status codes. The common one, clientTransferProhibited, is the “registrar lock” your registrar probably sets by default. It stops a domain from being transferred to another registrar — useful, and every ICANN-accredited registrar honors it. But it’s client-side: it lives at your registrar, controlled by your registrar account. If someone owns that account, they can flip it off along with everything else. It defends against the accidental transfer, not the compromised login.
The stronger thing is a registry lock: serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited, set at the registry, one level up. With it on, changes to your domain’s critical properties require out-of-band, manual verification — a phone call, a passphrase, a human on the registry side confirming it’s really you. Which means even if an attacker fully owns your registrar account, they still can’t transfer, delete, or repoint the domain. The one attack path that routes around your entire security stack finally has a lock on it.
Almost nobody uses it. It’s not the default, it usually costs a little, it’s mildly annoying to change things when you legitimately need to, and it’s invisible until the day it saves you. So the domains that have registry lock tend to be the ones run by people who already got burned, or watched someone else get burned, and decided the annoyance was cheaper than the outage.
If you run anything that matters — a bank, a package registry, the domain your whole company’s email flows through — the calculus isn’t close. The Brazilian bank had world-class infrastructure and lost everything for five hours through an account. Perl.com had 30 years of goodwill and nearly lost its name to a fax machine’s worth of forgery.
The registrar is the top of your stack, and most people leave the top of their stack protected by a password and the hope that a support agent has a good day. Turn on the registry lock. It’s the cheapest insurance in your whole security budget, and it’s aimed at the one door everything else assumes is already closed.