A spear-phishing attack this week hooked a customer service employee at GoDaddy.com, the world’s largest domain name registrar, KrebsOnSecurity has learned. The incident gave the phisher the ability to view and modify key customer records, access that was used to change domain settings for a half-dozen GoDaddy customers, including transaction brokering site escrow.com.
Escrow.com helps people safely broker all sorts of transactions online (ironically enough, brokering domain sales is a big part of its business). For about two hours starting around 5 p.m. PT Monday evening, Escrow.com’s website looked radically different: Its homepage was replaced with a crude message in plain text:
DomainInvesting.com’s Elliot Silver picked up on the change and got a statement from Matt Barrie, the CEO of freelancer.com, which owns escrow.com.
“During the incident, the hackers changed the DNS records for Escrow.com to point to to a third party web server,” Barrie wrote, noting that his security team managed to talk to the hacker responsible for the hijack via telephone.
Barrie said escrow.com would be sharing more details about the incident in the coming days, but he emphasized that no escrow.com systems were compromised, and no customer data, funds or domains were compromised.
KrebsOnSecurity reached out to Barrie and escrow.com with some follow-up questions, and immediately after that pinged Chris Ueland, CEO of SecurityTrails, a company that helps customers keep track of their digital assets.
Ueland said after hearing about the escrow.com hack Monday evening he pulled the domain name system (DNS) records for escrow.com and saw they were pointing to an Internet address in Malaysia — 111.90.149[.]49 (that domain is hobbled here because it is currently flagged as hosting a phishing site). The attacker also obtained free encryption certificates for escrow.com from Let’s Encrypt.
Running a reverse DNS lookup on this 111.90.149[.]49 address shows it is tied to fewer than a dozen domains, including a 12-day-old domain that invokes the name of escrow.com’s registrar — servicenow-godaddy[.]com. Sure enough, loading that domain in a browser reveals the same text that appeared Monday night on escrow.com, minus the redaction above.
It was starting to look like someone had gotten phished. Then I heard back from Matt Barrie, who said it wasn’t anyone at escrow.com that got phished. Barrie said the hacker was able to read messages and notes left on escrow.com’s account at GoDaddy that only GoDaddy employees should have been able to see.
Barrie said one of those notes stated that certain key changes for escrow.com could only be made after calling a specific phone number and receiving verbal authorization. As it happened, the attacker went ahead and called that number, evidently assuming he was calling someone at GoDaddy.
In fact, the name and number belonged to escrow.com’s general manager, who played along for more than an hour talking to the attacker while recording the call and coaxing information out of him.
“This guy had access to the notes, and knew the number to call,” to make changes to the account, Barrie said. “He was literally reading off the tickets to the notes of the admin panel inside GoDaddy.”
In a statement shared with KrebsOnSecurity, GoDaddy acknowledged that on March 30 the company was alerted to a security incident involving a customer’s domain name. An investigation revealed a GoDaddy employee had fallen victim to a spear-phishing attack, and that five other customer accounts were “potentially” affected — although GoDaddy wouldn’t say which or how many domains those customer accounts may have with GoDaddy.
“Our team investigated and found an internal employee account triggered the change,” the statement reads. “We conducted a thorough audit on that employee account and confirmed there were five other customer accounts potentially impacted.”
The statement continues:
“We immediately locked down the impacted accounts involved in this incident to prevent further changes. Any actions done by the threat actor have been reverted and the impacted customers have been notified. The employee involved in this incident fell victim to a spear-phishing or social engineering attack. We have taken steps across our technology, processes and employee education, to help prevent these types of attacks in the future.”
There are many things domain owners can and should do to minimize the chances that domain thieves can wrest control over a business-critical domain, but much of that matters little if and when someone at your domain name registrar gets phished or hacked.
But increasingly, savvy attackers are focusing their attention on targeting people at domain registrars, and at their support personnel. In January, KrebsOnSecurity told the harrowing story of e-hawk.net, an online fraud prevention and scoring service that had its domain name fraudulently transferred to another provider after someone social engineered a customer service representative at e-hawk’s registrar.
Nation-state level attackers also are taking a similar approach. A massive cyber espionage campaign targeting a slew of domains for government agencies across the Middle East region between 2018 and 2019 was preceded by a series of targeted attacks on domain registrars and Internet infrastructure firms that served those countries.
While there is very little you can do to prevent your domain registrar from getting phished or tricked by scammers, there are several precautions that you can control. For maximum security on your domains, consider adopting some or all of the following best practices:
-Use 2-factor authentication, and require it to be used by all relevant users and subcontractors.
-In cases where passwords are used, pick unique passwords and consider password managers.
-Review the security of existing accounts with registrars and other providers, and make sure you have multiple notifications in place when and if a domain you own is about to expire.
-Use registration features like Registry Lock that can help protect domain name records from being changed. Note that this may increase the amount of time it takes going forward to make key changes to the locked domain (such as DNS changes).
-Use DNSSEC (both signing zones and validating responses).
-Use access control lists for applications, Internet traffic and monitoring.
-Monitor the issuance of new SSL certificates for your domains by monitoring, for example, Certificate Transparency Logs.