New MitM attacks impersonate banking sites without triggering alerts
PhishLabs has observed a new wave of "Man-in-the-Middle" (MitM) attacks targeting users of online banking and social media. Customers of more than 70 different financial institutions are being targeted.
In these attacks, hackers use spam to deliver malware that changes DNS settings and installs a rogue Certificate Authority (CA). The DNS changes point to the hacker's clandestine DNS name server so that users are directed to proxy servers instead of legitimate sites. Based on the CA, the user's PC trusts the attacker's proxy servers and provides no indication that an attack is taking place. The browser displays the proper website name and displays the familiar security icon to indicate a trusted, secure connection.
The hacker's proxy sits between the authorized user and the real website, capturing login credentials and injecting code into the browsing session. This allows the hacker to take total control of the user's account and carry out unauthorized banking transactions as well as other actions.
Figure 1: Comparison of normal banking session (left) to hacked session (right)
Attack Delivery
The hacker initiates these attacks by using spam to deliver malware to victims via malicious attachments. In the cases observed by PhishLabs, these spam emails contain a message designed to entice the user to open an attached RTF (Rich Text Format) document. The document contains an OLE (Object Linking and Embedding) object which is actually an executable program file. This program is the malware which changes the DNS and Certificate Authority settings that allow the attack to be performed without any outward signs visible to the user.
Figure 2: EXE file disguised as a RTF document
On many systems, double-clicking an embedded program will execute it. Cybercriminals may use tools to create specially crafted RTF document files that display a familiar data file icon and a caption in most popular word processing programs; thus hiding or obscuring clues to the executable nature of the object, such as the EXE filename extension.
The Malware
The malware embedded in the spammed documents is a backdoor RAT (Remote Administration Tool) with an initial payload containing instructions to change DNS and security settings when initialized. The file is a Win32 PE (Portable Executable) EXE file and is actually a compiled form of an AutoIt script. The AutoIt scripting tools used offer the option to obfuscate the compiled code, and the version used to produce this malware makes it more difficult to decompile or reverse engineer the resulting EXE file than earlier versions. Some but not all of the samples found have been run through a second "cryptor" to aid in evading detection by anti-malware tools.
Changes to DNS
One of the first actions performed by the malware is changing the DNS settings on the infected user's PC. The malware configures the PC to use the hacker's rogue DNS server to look up names like "www.example.com" and translate them to a numeric network address that is used to locate and connect to the remote system. For domain names of certain targeted websites, the hacker's DNS server is configured to give the infected PC a bogus IP address that points to a proxy server impersonating the actual website being targeted. This causes the user to connect to a system that the hacker can use to spy on and manipulate sensitive data intended for a legitimate website.
Multiple DNS and proxy servers have been observed being used in these attacks, typically one each per geographic region. For example, the infected PCs of online banking users in South America would be configured to use one DNS server, while those in Western Europe are configured to use another.
The attacker's DNS servers run the BIND nameserver software, and the attackers appear to remotely configure their DNS servers via the rndc utility on port 953/tcp.
Faked Security Credentials
The second essential change made by the malware is the installation of a root certificate for a rogue CA. Once installed, practically everything that uses certificates signed by the rogue CA, such as secured website connections, is trusted implicitly by the infected user's system. The user will not be alerted by any certificate error warnings.
Figure 3: Bogus certificate issuer identity
Certificates used in these attacks impersonate a well-known and widely trusted CA, but this information is controlled by the hacker who generates the certificate; this field could contain anything that the hacker wishes. However, the actual digital signature is not forged and does not match the identity of the legitimate CA.
Figure 4: Comment field indicating certificate was generated using "easy-rsa"
A closer look at the certificate information reveals that the certificate was generated using "Easy-RSA" (also known as "easy-rsa" with all lowercase letters), which is a set of scripts previously distributed along with the free OpenSSL utilities that allow users to generate certificates. The easy-rsa tools were designed to make it easy for inexperienced users to create self-signed certificates, using their own private version of a CA. The data in this field is generally not provided by the user, and it's a bit more difficult to modify from the default. In fact, certificates issued by the legitimate CA impersonated in these attacks do not even contain this optional "Netscape Comment" field.
Impersonating Targets
With the changes to DNS and trusted CAs in place, the attacker can now easily and seamlessly impersonate secured connections to known web sites using a proxy server:
- The victim clicks a link and either chooses a bookmark or enters a web address (i.e. https://banking.example.com) into the browser.
- The victim's computer asks the attacker's rogue DNS server for an IP address for "banking.example.com"
- Instead of the actual IP address for the real bank, the DNS server answers with the IP address of the attacker's web server
- The victim's computer connects to the attacker's web server and initiates an online banking session
- The attacker's webserver runs proxy software that sits in the middle of the connection, forwarding user requests to the bank and responses from the bank back to the user
From the attacker's vantage point as the "man in the middle", he can not only see all of the information passing between the victim and the bank; he can also modify the information to hide warnings, ask for additional security information, lock out the user, or even create new requests to initiate unauthorized transactions.
From the user's perspective, the bank name and secure connection indicators all match and there is no sign that anything other than a normal online banking session is transpiring.
From the bank's perspective, practically everything appears to be normal too. The attacker's proxy passes any fingerprinting codes or cookies to the victim's browser and returns the correct matching results to the bank's webserver.
Under otherwise normal conditions, the only indication that the bank might have is that the user's IP address for the connection will be that of the clandestine proxy server, not the actual IP address of the victim's computer. However, a security policy based solely on this indicator is impractical because IP addresses can and do change, and users log in from other locations on occasion. Instead, the proxy servers used in these attacks must first be identified and the IP addresses added to a blacklist. This threat intelligence item is key to effective attack detection and fraud prevention by the bank.
Monitoring Clandestine DNS/Proxy Servers
Both the name servers and the proxy web servers have been set up and configured specifically for use in these attacks. That is, they are not compromised servers repurposed by the attacker.
In each of the attacks studied, the DNS service (including the rndc service) and the web proxy services were running on the same server with the same IP address. None of the attacks used separate servers for DNS and web proxy services. The servers were located on hosting company networks in the UK and in Central or Eastern Europe. Victims are not deliberately routed to servers in the same geographical regions, so flagging for possible fraud and abuse based on geolocation of the originating IP address may be feasible for some financial institutions.
Figure 5: Rogue DNS/proxy servers (red) handle domains for targets in each general area
PhishLabs has been able to locate four of the rogue DNS/proxy servers and the target groups for each of them. More than 70 financial institutions have been actively targeted. The servers were configured to proxy traffic for an additional 25+ websites in order to siphon off credentials for email, social media, and other accounts of value.
PhishLabs continues to monitor these attacks and is working with others to mitigate the threat.