Domain Mayday EP10: How the Syrian Electronic Army Took Down NYTimes.com Through a Phished Reseller

A newspaper's domain name is its front door. When you type nytimes.com, you are trusting an invisible chain — a domain registry, a registrar, sometimes a reseller underneath that registrar — to point you at the real newsroom and nowhere else. On a normal day you never think about that chain. On August 27, 2013, it broke, and millions of readers walked up to the front door of The New York Times to find it had been swapped for someone else's.

The someone else was the Syrian Electronic Army (SEA), a pro-Assad hacker collective that spent 2013 picking off Western media outlets. This time they did not deface a single article or break into a content management system. They went one level deeper — into the DNS records that decide where a domain points — and for a few hours they owned the address of one of the most-read news sites on the planet.

A domain is the front door, and the front door has a lock you don't control

When a company like The New York Times registers a domain, the authoritative record of "who owns this and where does it point" lives at the registry (for .com, that is Verisign) and is managed through a registrar. Large registrars also sell through resellers — smaller firms that resell domain services and hold their own login to the registrar's systems.

That layering is convenient. It is also a chain of trust where the weakest link sets the security of the whole thing. If an attacker can authenticate as anyone in that chain — registrant, registrar staff, or reseller — the registrar's systems will, by design, treat them as the legitimate owner. Melbourne IT's own chief executive put the failure mode in one devastating sentence: "They came in through the front door," he told the AP. If you have a valid username and password, the system assumes you are the authorized owner. That is the whole problem in a nutshell.

August 27, 2013: the day nytimes.com pointed somewhere else

Late on a Tuesday afternoon, readers stopped reaching the Times. The New York Times website had "gone dark for some users," ABC News reported, and the paper confirmed its site was "unavailable to readers on Tuesday afternoon" following an attack on its domain registrar. This was not a brief blip. Visitors "were greeted with blank browser screens for several hours on Tuesday," the Christian Science Monitor reported — and to make it worse, it was "the second time this month" the site had gone down.

What had actually happened was a DNS hijack at the registrar level. The attackers reached into the records that translate nytimes.com into an IP address and rewrote them. Per Wikipedia's account of the incident, NYTimes.com "had its DNS redirected to a page that displayed the message 'Hacked by SEA'". The front door had been re-hung over a different doorway.

The Times was not the only target on that account. TechCrunch, reporting in real time, found that both "The New York Times and Twitter name servers appear to have been registered through the registrar Melbourne IT," and that the twimg.com domain, "which serves up Twitter images and avatars, also shows changes that point to servers that are apparently SEA-owned." Twitter's main site survived largely intact, but its image-and-avatar domain wobbled — enough that some users briefly saw broken images.

The impact: hours of darkness, and a redirect you couldn't trust

For a news organization, the cost of a hijack is not measured only in lost pageviews. It is measured in trust. For the duration of the outage, anyone reaching nytimes.com was being routed by the attacker. The Times' own chief information officer, Mark Frons, told staff the disruption "was the result of a malicious external attack by the Syrian Electronic Army or someone trying very hard to be them" — and warned employees to be cautious with email while the domain was out of the paper's hands.

Think about what a hijacked DNS record actually enables. The attacker controls where the name resolves, which means they can serve a defacement page (as they did), but they could just as easily serve a convincing fake login, harvest credentials, or intercept traffic. A defacement is loud and obvious. A quiet DNS hijack is far more dangerous — and the same weakness enables both. The Huffington Post UK's domain was caught up in the same incident, underscoring that this was a registrar-account compromise, not a one-off prank against a single newsroom.

How it happened: phish the reseller, not the newspaper

Here is the part worth sitting with: the SEA never had to break into The New York Times. They never touched the paper's servers or its CMS. They attacked the chain beneath the registrar.

The entry point was a spear-phishing email sent to a US-based reseller of Melbourne IT. As The Next Web reported, Melbourne IT "confirmed that the SEA used phishing tactics to get hold of the log-in details" — staff at the reseller were tricked into handing over their email credentials, and the attackers then mined those mailboxes for the registrar logins. From there it was simple: the credentials "of a Melbourne IT reseller (username and password) were used to access a reseller account on Melbourne IT's systems," and once inside, the attackers "changed the DNS records of several domain names ... including those for The Times."

TechCrunch's account is equally blunt: the "DNS records of several domain names on that reseller account were changed – including nytimes.com."

This is the asymmetry that makes registrar-chain attacks so attractive. The Times could harden its own infrastructure to the moon and it would not matter, because the vulnerable account belonged to a third-party reseller several steps removed from the newsroom. A spear-phish against a few employees at one small company was enough to redirect a newspaper read by millions.

Response and aftermath

Once Melbourne IT understood what had happened, the remediation was straightforward — and it shows how reversible these attacks are if you control the registrar. The company restored the correct settings: it reverted the altered DNS records and "locked" them down against further alteration. It changed the password on the compromised reseller account and pulled logs to trace the intrusion. The Times restored service by early Wednesday.

But the most instructive detail in the whole episode is why the damage stopped where it did. Some domains on that same reseller account were never affected at all — because their owners had turned on a stronger protection. In Melbourne IT's own words, for "mission critical names we recommend that domain name owners take advantage of additional registry lock features available from domain name registries including .com – some of the domain names targeted on the reseller account had these lock features active and were thus not affected."

A registry lock places the domain in a state (you can see it in WHOIS as flags like serverUpdateProhibited) where the registry will refuse changes unless a stricter, out-of-band process is followed. As domain-industry watchers noted at the time, Twitter's records carried exactly that kind of Verisign-lock status. A phished reseller password is not enough to defeat a registry lock — and that single configuration choice is the line between "down for hours" and "never affected."

What this teaches about registrar and reseller chains, and registry locks

The August 27 hijack is a near-perfect teaching case because every link in the failure chain is visible.

1. Your domain is only as secure as the weakest account that can change it. That includes your registrar's staff and any reseller beneath them — none of which you control directly. The Times did nothing wrong on its own servers; the compromise was several steps removed.
2. Phishing beats firewalls. No exotic exploit was used. A fake email to a handful of reseller employees produced credentials that the registrar's systems treated as fully authorized. "They came in through the front door."
3. Registry lock is the control that actually mattered. The domains with additional registry lock features "were thus not affected." For any mission-critical domain, registry lock (plus registrar-lock and 2FA on the registrar account) is not optional hardening — it is the baseline.
4. DNS changes are powerful and fast. A single rewrite of name-server or A records redirects an entire brand instantly. The blast radius of one compromised account is every domain it can touch.
5. Monitor your own records. WHOIS and DNS monitoring would have flagged the unauthorized change in minutes. The earlier you notice an unexpected name-server change, the smaller the outage.

The Namefi angle

The SEA hijack was, at its core, an authority problem. The registrar's system could not tell the difference between the real owner and someone holding a phished password, so it did what it was built to do and accepted the change. Every defense that worked — registry locks, out-of-band confirmation, careful monitoring — is really a way of raising the bar for proving that a change request truly comes from the owner.

Namefi starts from that exact premise: domain ownership and control should be verifiable and tamper-resistant, not a single reusable password floating through a reseller's inbox. By representing domain ownership as an on-chain, cryptographically verifiable asset that stays compatible with DNS, Namefi makes "who is allowed to change this domain" a question with a strong, auditable answer rather than an implicit trust in whoever logged in. Control changes become explicit, signed actions tied to the owner — closer to a registry lock you hold the key to than to a front door whose lock anyone with the right password can open.

A newspaper's domain is its front door. The lesson of August 27, 2013 is that the strongest possible deadbolt does no good if a stranger several buildings away can be tricked into handing over a copy of the key. The fix is to make ownership itself provable — so that "came in through the front door" stops being a thing a stranger can ever say.

Sources and further reading

• The Register — New York Times, Twitter domain hijackers 'came in through front door'
• TechCrunch — Syrian Electronic Army Apparently Hacks DNS Records Of Twitter, NYT Through Registrar Melbourne IT
• ABC News — New York Times Website Hacked, Syrian Electronic Army Appears to Take Credit
• Christian Science Monitor — New York Times hacked, Syrian Electronic Army takes credit
• iTnews — Melbourne IT compromise redirects NY Times, HuffPo readers
• The Next Web — Here's How the New York Times and Twitter Got Hacked
• Domain Name Wire — Melbourne IT the weak link as Twitter and NY Times domain names compromised
• Wikipedia — Syrian Electronic Army
• NBC News — Syrian group hacks Twitter, New York Times
• Al Jazeera — Syria hackers target New York Times website