Archived Blog

In the labs we like to go over URLs flagged as suspicious by ThreatSeeker. When we were going over those URLs last week we noticed an interesting file which came in through a spammed URL. As ThreatSeeker began quarantining the suspected messages, we decided to investigate the file that the suspected URL led to so we could see if it might be interesting in any way.

The URL was part of spammed email in Spanish which announced a promotion by the phone company Claro. It featured a picture of the promotion, and clicking on the image led to an executable. From an initial look at the executable, it had the name PremiosClaro.exe and looked small enough to be a downloader, written in VB, not packed, and with very low AV detection rates. 

 

Trojan's first phase

Starting up the little file causes the default browser to open in an actual Claro promotion page. Covertly, the Trojan downloads another file from a hacked sports Web site, and the downloaded file is nicely camouflaged with the name stat.d under a legitimate directory, called stats, in the site itself. 

 

Phishing Kit Installation

Now the fun begins. stat.d is a self extracting archive which contains a well-structured phishing kit (see screenshot) prepared to be installed on the victim’s computer. The Trojan installs the kit in a newly created folder named config, located under the Windows system32 folder. The kit installs with a list of commands to be executed; these are programmed in the archive itself inside a VBS file. The VBS file, called jute.vbs, is executed by Windows Based Script Host once the archive is extracted. Here is the sequence of scripts/commands it executes (also, see the screenshot):
1. Peru.bat -> contains a script that modifies the Windows host file to point several financial/bank sites into the local host address (127.0.0.1).
2. Firewall.exe and Updater.exe get executed to kick start the Phishing sites on the local computer (Firewall.exe is the component that actually listens on port 80).
3. Inicio.bat -> uses Windows native Registry Console Tool to add Firewall.exe and Updater.exe to the system’s startup.


This is a double-edged kind of attack. This Trojan installs components intending to phish for the local user’s bank information details, and also to turn the machine into a fully functional phishing site.

Phishers benefit from this kind of attack in these ways:

1. Phishers can phish for credentials locally on the victim’s computer; they don’t have to rely on a remote Phishing site which might be blocked or brought down at some point. The phishing site is local to the computer and always available.
2. Phishers get to use compromised machines as Phishing serving points, which saves them a lot in terms of hardware and maintenance costs. (No need to pay for hosting providers or hack Web sites).
3. Phishers can use these compromised computers to participate in Fast-Flux Phishing attacks to create a high-redundancy Phishing network.
This attack looks popular, as I spotted another Trojan of this kind at the beginning of this week.


Malcode Analysis

1. PremiosClaro.exe

This is the downloader component, written in Visual Basic. It doesn't do anything fancy besides downloading the self-extracting archive described above, and distracting the user by opening the default browser in a Claro promotion page. In order to do that, the malware uses the UrlDownloadToFileA function. If you look into the imported functions, you won't see that function imported, neither LoadLibrary nor GetProcAddress, but it will still use this urlmon function.

In fact, VB applications have a special wrapper to load API functions. Therefore, if a programmer uses a function that isn't from the VB runtime, you will find something like this: 



Although, this is fairly well-known by reverse engineers, we thought we could explain how it works to people unfamiliar with VB.

Basically, the parameter passed to this function is a structure with a pointer to the dll we want to load a function from, and a pointer to the actual function that we want to execute from the dll. When calling the "DllFunctionCall", the wrapper loads the LoadLibrary and GetProcAddress calls, and returns the address of the function we wanted to execute.

Right after the call to the wrapper, we have a "JMP EAX", which actually executes our function. If we want to find where the function is actually called from, we have to follow cross references to the whole wrapping function.

Besides this, there are obfuscated strings in this binary, in order to hide the actual URL. Instead of plain text, you will find strings such as: 



In order to locate the routine that will decode those strings, we need to look at their cross references, and at the code close to it.

In 90% of the cases, you will find a call to a function below, and that same function will always be called after the strings are pushed onto the stack.

This is the decoding function...the one you might want to reverse engineer (if you're bored or want to impress people ;) or "hook" in order to log all the decrypted strings.

When you are actually lacking time to write a proper decoder, you can script the logging of decrypted strings. Then, use an IDC script to insert comments in your analysis, with the decrypted content, without bothering with the algorithm, which is going to be weak anyway.

2. updater.exe

This is the updating component. It updates the rogue Web site hosted by the infected machine. (See firewall.exe for more information). Updater.exe first uses InternetOpenA to visit a link hardcoded inside of the malware.
It's actually some sort of "bouncer". Indeed, when you visit that page you get yet another link, the actual URL to the file to be downloaded.

 

Our application then calls UrlDownloadToFileA to save that page as "form.js" on the local machine, in a special folder. That folder already has a "form.js", which gets updated every time update.exe connects to the hardcoded link.

Indeed, there is already a "form.js" in the Phishing kit; it's a little script used to POST data (credentials) on an external Web site. By dynamically updating the "form.js" file, the Phishing kit stays up-to-date, even if the page stealing credentials is shut down.


3. firewall.exe

Firewall.exe is the actual webserver hosting a Phishing kit on the infected machine. Once the local host file has been modified, a few bank Web sites are redirected to localhost, ending up displaying the rogue bank page.

At this point, when somebody enters his credentials, his data is actually sent to a remote Web site controlled by the attackers. Game Over.

By reverse engineering this file, we found out that it visits yet another link. Normally, that page returns the word "activado", which means the HTTPd must start. Otherwise, firewall.exe just exits. 



aka: "Mayday, cops are on our tracks, it's time to disable everything for a while." ;-)

Conclusion

This kind attack looks popular; we spotted another Trojan Downloader of this kind spammed at the beginning of this week. As of this moment, all the URLs contacted by the local Phishing kit components are still alive. Most of them are of compromised Web sites, and we see compromised Web sites used for Malware purposes a lot lately -- more than ever. The fact that sites can be created dynamically, like we presented, and virtually everywhere, really makes one realize how dynamic URLs can be, and that static URL categorizations are obsolete. On another note, no security researcher is really surprised to find Phishing sites' DNS servers pointing their A records to ISPs' private users' address ranges.

In today's world, when most corporate networks don't have distinct borders, and most have mobility in mind, these kinds of attacks become more dangerous than ever. The malware components are interesting enough and have some level of sophistication, but we have reached the conclusion that this is certainly not the highest-level of sophistication at all. We do expect to see an evolution in that manner where kits like these would become far more sophisticated.

Security Researcher: Elad Sharf, Nicolas Brulez