An organization’s domain name may be its most important asset, and losing control over it affects more than its website. For a large Brazilian bank, a domain hijacking operation last fall resulted in attackers stealing payment card data, taking over customer accounts, and infecting customers with malware.
While the actual bank heist began on Oct. 22, 2016, at around 1 p.m., the preparations for the attack were underway at least five months in advance, said Kaspersky Lab researchers Fabio Assolini and Dmitry Bestuzhev at last week’s Security Analyst Summit. The sophisticated cybercrime group gained access to the bank’s domain registrar and modified the Domain Name System (DNS) records for the bank’s all 36 online properties.
DNS translates human-friendly domain names to the IP address of the servers hosting the website or the application. By changing the DNS record, the attacker can reroute all users to some other destination than the actual server even though the user is using the correct web address. In this massive bank fraud operation, the group sent the bank’s customers to near-perfect copies of the bank’s sites hosted on Google Cloud Platform.
The researchers originally thought the attack was simply another site-hijacking-and-phishing operation, but quickly realized the attackers were interested in more than harvesting login credentials and downloading malware: They had taken over the bank’s entire internet presence.
“All domains, including corporate domains, were in control of the bad guy,” Assolini said.
Complete pwnage
The attackers, believed to operate out of Brazil, interfered with the bank’s online banking, mobile app, point-of-sale terminals, ATMs, and investment transactions. By routing the ATM and point-of-sale systems, the attackers collected payment card details for anyone who used their credit or debit cards during the attack window. Anyone who attempted to access the bank’s sites were infected with malware, which stole login information and email contact lists from Outlook and Exchange. The attackers phished credentials from everyone logging into the online banking application. A phishing campaign targeted specific banking clients.
It took five to six hours for the bank’s security team to regain control. Even worse, the bank couldn’t notify its customers of the attacks because the attackers controlled the domains used by the bank’s email and FTP servers. Employees couldn’t even communicate with each other.
“What were they going to do, use Yahoo? ‘Hi, I am the security officer of your bank.’ Yeah, that’s not going to work,” said Bestuzhev, director of Kaspersky’s research and analysis team in Latin America.
While researchers still don’t know the full extent of the damage, the attack is a wake-up call for banks and other organizations to consider how the insecurity of their DNS could result in a complete loss of control of their online presence.
“If your DNS is under the control of cybercriminals, you’re screwed,” said Bestuzhev.
This kind of domain hijacking isn’t unusual, as attackers tamper with DNS records to send users to malicious websites. For example, back in 2013, the Syrian Electronic Army successfully hijacked The New York Times domain to a page displaying its logo. Experts have long warned that DNS is vulnerable to attack and needs better security, but those warnings frequently get drowned out with other, more immediate security concerns.
“This is a known threat to the internet … but we’ve never seen it exploited in the wild on such a big scale,” said Bestuzhev.
It all began with the domain name
The attackers compromised the bank’s DNS provider Registro.br and gained control of the bank’s DNS records, but the researchers still don’t know what method they used. Back in January, the registrar had disclosed a cross-site request forgery vulnerability in its website that would have let a malicious actor authenticate to accounts, but the registrar claimed the flaw was not used during the bank heist, Bestuzhev said. The initial attack vector could have been as mundane as a spear phishing email sent to employees at the registrar.
If the victim employee had access to the DNS tables, the damage the attackers could have caused would be far more widespread than taking over a single bank, Besuzhev said.
Because the bank didn’t use two-factor authentication, though the registrar offered the security option, the attackers were able to access the account and change the information for all the DNS records. Two-factor authentication could have prevented the compromise or at least warned the bank’s defenders that something unexpected was happening.
Elements of the operation
With the domain under their control, the attackers needed a place to direct the users, so they went to the cloud. The bank’s desktop and mobile website domains were painstakingly cloned on Google Cloud and used valid certificates issued in the bank’s name by free certificate authority Let’s Encrypt. The sites looked the same as always, and the browser showed the correct URL, HTTPS, and the closed padlock icon. No wonder the users were fooled.
Users visiting the bank’s website during the course of the attack were infected by a malicious .JAR file masquerading as an update to the bank’s Trusteer security plugin. Once installed, the malware used Avenger, a legitimate penetration testing tool, to disable existing security software installed on the victim’s computer. A different module collected login credentials, email and FTP information, and email contact lists from Outlook and Exchange. Another part of the malware looked to see if the victim had accounts with other banks in Brazil, the United Kingdom, Japan, Portugal, Italy, China, Argentina, the Cayman Islands, and the United States and attempted to harvest those login credentials.
The choice of Google Cloud was interesting. Since the attacker’s infrastructure had better performance and reliability than the bank’s own datacenter operations, IT never got warnings from customers or employees about slow performance or sluggish service, Besuzhev said.
There was one silver lining for the bank’s defenders: The bank’s mobile app used certificate pinning, a security mechanism designed to prevent attackers from impersonating websites with fraudulent certificates. As a result, attackers were unable to cause much damage via the app.
DNS needs to be secured—period
The internet relies on DNS, and DNS is notoriously fragile. Many organizations rely on a third-party provider for their DNS infrastructure—the outage with Dyn last fall highlighted that fact very clearly—which makes them particularly vulnerable to this type of attack. Regardless of who controls the DNS, the organization still has to enable the security protections.
Not all registrars offer two-factor authentication to protect the accounts, but even for those that do, customers don’t bother to turn on that security layer. Some registrars offer DNSSEC, a type of registry lock to prevent DNS records from easily being modified, but it is not widely used.
While the bank ultimately regained control, likely by calling (or faxing!) the registrar to fix the DNS records, the victim machines are still infected with malware and could still be stealing information from victims, the Kaspersky researchers said. To give a sense of scale, the researchers described the bank as a large institution with more than $25 billion in assets, 5 million customers worldwide, 12,000 employees, 1,000 endpoints, and 500 branch locations in Brazil, Argentina, the United States, and the Cayman Islands.
Organizations should have incident response teams dedicated to keeping an eye on the domains and DNS issues so that they can detect these kinds of changes faster, Bestuzhev said. If all the attacker has to do is to take over the domain name, then it doesn’t really matter how locked down the network is, how secure the application and website is, or what layers of security the defenders may have in place.