Attacks/Breaches
8/29/2013
02:54 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Lessons Learned From N.Y. Times Hack Attack

How could the Times have recovered faster after the Syrian Electronic Army attacked its DNS registry? Here are six considerations to help protect your business from similar harm.

The Syrian Electronic Army: 9 Things We Know
(click image for larger view)
The Syrian Electronic Army: 9 Things We Know
What might The New York Times -- and to a lesser extent, Twitter -- have done differently to prevent Tuesday's hack attack that disrupted access to their sites?

The disruptions began after the Syrian Electronic Army (SEA), a group of hackers that back Syrian President Bashar al-Assad in the country's civil war, hacked into the systems of the world's sixth largest domain name system (DNS) registrar, Melbourne IT, and altered DNS settings for nine sites.

Twitter quickly restored service, but by Thursday afternoon, people were still reporting difficulties accessing the Times website. "If you're still having issues, it's likely the result of your ISP not yet restoring proper DNS records," Times spokeswoman Eileen Murphy tweeted Wednesday.

While those cleanup efforts continue, here's how other businesses can help themselves avoid a similar fate:

1. Beware Spear-Phishing Attacks

According to Melbourne IT chief executive Theo Hnarakis, the SEA was able to hack the affected sites' DNS settings after launching a successful spear-phishing attack against one of Melbourne IT's U.S. resellers, which he declined to name. The phishing attack allowed the hackers to access employees' email, from which they retrieved log-in credentials for both the Times and Twitter DNS configuration pages.

"This activist group used a very, very sophisticated spear phishing attack," Hnarakis told the Associated Press (AP). " They sent very dubious emails to staff of one of our resellers whose area of expertise is looking after the domain names for major corporates including the New York Times."

"Unfortunately, a couple of the staff members of the reseller responded by giving their email log-in details; the group were able to search their emails for sensitive information that included the username and password for The New York Times, and from there it all cascades," he said.

2. Train Users To Spot Phishing Attacks

What could Melbourne IT's reseller have done differently? For starters, it might have better educated employees to recognize and resist phishing attacks. "Humans [are] once again the weakest link," tweeted Brian Honan, CEO of the Irish Reporting and Information Security Service, which is Ireland's CERT, about the hack. "Malware and attackers no longer target the operating systems but the [users] instead."

Unfortunately, attackers only need one phishing attack to be successful, and the odds are on their side. According to a phishing study conducted at North Carolina State University, 89% of participants claimed to be proficient at recognizing malicious emails. But when assessing whether an email was malicious or legitimate, 92% of study participants incorrectly classified at least some emails.

3. Monitor DNS Settings In Real Time

The SEA hacked the DNS settings for both the Times and Twitter, among other sites, yet Twitter emerged relatively unscathed. What was its secret? HD Moore, chief research officer at Rapid7, told Bloomberg that Twitter actively monitors its DNS settings and thus learned of the hack very quickly.

Ben April, a senior threat researcher at Trend Micro, said in a blog post that commercial monitoring services or even "a small shell-script" can do the job, but warned that neither of those approaches will prevent attacks, although "would have shortened the time to repair."

What exactly should businesses monitor? According to Dell SecureWorks' Counter Threat Unit (CTU) research team, watch "for changes to registration information and DNS resolution to IP addresses" on all business-critical domains.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
David F. Carr
50%
50%
David F. Carr,
User Rank: Apprentice
8/30/2013 | 1:23:15 PM
re: Lessons Learned From N.Y. Times Hack Attack
Is there something website operators can do to get visibility into all the subcontractor relationships between different organizations involved in the management and maintenance of DNS records? Seems like simplifying the chain of command might be one way to minimize the chance of problems like this.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web