Stolen signing certificate leads to banking trojan

>We see a lot of crimeware, particularly crimeware that targets banking information. That said, we’re still occasionally surprised not only by the ingenuity of threat actors, but sometimes by their hubris. Some perspective . . .

As an attacker, you want to introduce as few moving parts as possible. Each piece of software that you introduce increases the likelihood of detection thus decreasing the likelihood that you will achieve your objective. So, actors are adopting tools similar to Poweliks and Kovter, packing their naughty bits into surreptitious locations and leveraging native tools for execution. A lack of traditional, easily detectable Portable Executable (PE) file drops coupled with execution by way of native tools such as Powershell results in quiet installation, lower detection rates, and thus an increase in successful attacks.

With the above in mind, the only explanation for what you’re about to see is the saddest explanation of them all: Despite the noise, stuff like this still works.

Initial Stages – Stolen code signing certificate

The first stage of this attack looks much like any other software download, aptly named download.exe. Note the Publisher field, which indicates that this binary is digitally signed and that Windows was able to validate the trust chain. By signing the first stage, the attacker has a much better chance of evading detection.

Also take note of the signing time. This binary was signed only four hours prior to delivery. Software vendors update software, and thus we should expect to see recently signed binaries from time to time. Unfortunately, we have enough experience with stolen code signing certificates that we give added scrutiny to binaries with signing times within certain bounds, and “hours” is highly anomalous.

download.exe is actually a self-extracting archive that expands to installer.exe, an aptly named binary that will put into place a number of services and configurations that afford the attacker absolute control over both the operating system as well as any browser-based communications. Note that installer.exe is signed with the same stolen certificate, again helping to bypass simple checks on the platform side that may warn or block the user when an unsigned binary attempts to execute.

Installation and persistence

First, installer.exe configures an OpenVPN endpoint complete with all of the key material and configurations required to immediately bring up the tunnel. Not shown here are the tap drivers installed by a child process, effectively providing an Ethernet bridge between the attacker and the victim.

Next, we see Privoxy installed. Privoxy is a non-caching proxy that can be run as a Windows system service. This could be used to manipulate the flow of traffic to and from certain sites, or it could be used to proxy traffic for the attacker through the victim (for instance, if the attacker needed access to a resource only available via the victim’s computer or network).

Lastly, the attacker delivers TightVNC, a portable remote administration and control tool. Using VNC, the attacker can operate the victim’s system as though he were at the console.

Once all of the software and configurations are in place, the installation routine spawns a number of child processes to:

• register the kernel driver via sc.exe
• generate key material and configuration files for OpenVPN
• set Privoxy to run at system startup
• install the TightVNC server service
• use netsh.exe to make firewall modifications for the above

Lastly, the installer forces an immediate reboot using the shutdown.exe command.

Upon reboot, OpenVPN initiates a connection with endpoint tysmqef8.ddns.net (189.1.164.142:1194). Analysis of port 443 at this IP address reveals a forged certificate purporting to be www2.bancobrasil.com.br. While this sequence of events clearly indicates an attack, we now know exactly what the attacker is attempting to access. At this point it is also worth noting that, due to the nature of this customer’s business, the victim here is very likely to have access to a corporate bank account.

Prevention and detection

As I mention in my introduction, this is a very noisy attack. If the attacker simply wants banking credentials, there are far more elegant solutions available for rent or purchase. For some reason, this attacker desires a deeper level of access to the victim endpoint, and this is the result.

This customer’s endpoint protection software and configuration control failed in a number of ways. Policies preventing execution of any binary from an untrusted zone would help, and blocking execution from temporary directories would have prevented installation as well. It’s arguable whether this could be detected from an antivirus standpoint, but a comprehensive endpoint protection suite should be expected to intervene.

Of course, where prevention fails detection must succeed. And fortunately, despite the presence of signed software and a lack of detection by not only antivirus software but also by additional endpoint protection components, Carbon Black delivers and this lit up our detector set like a Christmas tree:

• Use of dynamic DNS services: We check every external domain and IP against a variety of threat data holdings, but more importantly we look for some very simple observations that include the presence of dynamic DNS hostnames.
• Execution of globally unique binary files (our Newly Observed Binary mechanism): A simple but highly effective mechanism requiring that most new binaries be reviewed by our SOC.
• Modification of local firewall settings
• Registration of a new system service
• Exercise of common persistence mechanisms
• Execution from a user space directory
• Suspicious patterns of file cloning

A final point: Even in the face of prevention failures, powerful and timely detection can keep a successful infection from converting into a successful attack.

Using a tool like Carbon Black makes it easy to monitor for a variety of observable events. While you can’t predict the technical or tactical means by which threats will evolve, you can use always-on collection to establish baselines and detect any evolution within your environment.

Using the data coming out of Carbon Black coupled with our enrichment and detection engine, a significant number of events were raised within minutes of initial execution. And our SOC was able to near-immediately notify the customer, who isolated the endpoint on the network, heading off entry of any sensitive information on the compromised endpoint.