Dridex Malware Steals Millions from Online Bank Accounts

Warnings were issued yesterday by the US Computer Emergency Readiness Team (CERT) and the UK National Crime Agency about a piece of malware called Dridex, which is used for stealing money from online bank accounts. The malware itself is not new; it first emerged in July 2014, and is considered the successor to a previous piece of malicious software called Cridex. Its prevalence declined following the arrest of Andrey Ghinkul in August this year, and there had been hopes that this would continue. Instead, there has been a resurgence of cases.

Bank accounts are compromised by waiting for the legitimate user to visit one, recording the usernames, passwords and other credentials used to gain access, then sending those credentials to someone waiting to use them to fraudulently withdraw money. The groups responsible for this type of criminal activity are often highly organised, so there could be different individuals responsible for writing the malware, distributing it to victims and collecting the results, performing the initial withdrawals, and then laundering the money so that it cannot be traced. Those near the end of this chain are generally more expendable than those near the beginning.

In this instance, the authorities believed that they had disrupted part of this chain by disabling the ‘botnet’ of Dridex-infected computers, and by arresting a suspected administrator of that botnet. According to US Attorney David J Hickton, they had “struck a blow to one of the most pernicious malware threats in the world”. However, the effect appears to have been short-lived.

The primary infection vector for Dridex has been through phishing campaigns, whereby apparently innocuous e-mails are sent to potential victims in the hope that they will open an infected attachment – typically a Microsoft Word or Excel document in this instance. The attachment then downloads the malware itself from the internet and installs it on the computer. Bank credentials are harvested and sent back to the attackers.

Nettitude have seen many such phishing attempts, including one using 22 different variants of a malicious word document that will download and install Dridex if opened. Because there are so many variants, these documents are not listed in public databases of malicious files; and because they do not themselves perform any directly malicious action, they are less likely to be detected by antivirus software. However they are certainly not benign, and represent one of the most prominent threats we have encountered recently.

Losses due to Dridex have been estimated at £20m in the UK, and at least $10m in the US. Whether this continues to escalate will depend on how successful the authorities are in their continuing efforts to shut down the network. One of the technical methods used to achieve this is to take control of domain names or other assets used by the perpetrators, and redirect them to a benign location. Unfortunately these assets can be replaced so long as the organisation behind them remains in existence.

If you have a substantial amount of money at stake, the best way to protect yourself against this and other types of malware is to use a dedicated machine for internet banking. Other useful precautions include:

  • Bookmarking the bank website (to avoid typing errors)
  • Not clicking on links or attachments in e-mails unless you are confident that you trust their authenticity
  • Installing effective anti-virus protection, on operating systems where this is appropriate
  • Ensuring that your operating system and web browser are up to date, with all relevant security patches applied

Larger organisations should monitor their networks for signs of malware activity, for example, by subscribing to the Nettitude Threat2Alert service.

To contact Nettitude’s editor, please email media@nettitude.com.

New Malware Targets Financial Data

File Name: cclub14.exe
File Size: 1081833 byte
Compile Time: 2015-06-17 08:36:37
Sections: 4
Hash MD5: 29cf881ca840424f2dba7c0952a94cfe
Hash SHA-1: 85461a14c12a2e3f3f0f1f10a8d68d73e4e891b4
Imphash : 7ee226ca53c7ca1c7999e440384c5b89

Summary:

New malware that is not yet detected by most antivirus products was identified and studied by Nettitude yesterday. It targets financial information (in this case Bitcoin’s wallets). The malware has been designed to perform three key functions:

  1. Steal Bitcoin wallets
  2. It will attempt to steal login credentials from a large selection of file transfer software applications;
  3. The malware will also attempt to send large numbers of SPAM messages from the infected machine.

As a consequence of the large number of SPAM messages it generates, the IP of the victim is at high risk of being backlisted.

The download and execution of unknown files should be controlled in corporate environments, while home users should restrain themselves from downloading files that look suspicious.  It is believed that the file was received as an email attachment.

Investigation Log:

Nettitude’s CERT team investigated a customer who suspected they were under attack. At the time all actions on the host were being monitored and a copy of the recent network traffic was captured prior to the host being disconnected from the network.

The first immediately obviously thing the malware tried to do was access common locations for Bitcoin wallets  for every user profile present in the victims computer:

  • “C:UsersDefaultAppDataRoamingBitcoinwallet.dat”
  • “C:UsersPublicAppDataRoamingBitcoinwallet.dat”
  • “C:UsersXXXXXXAppDataRoamingBitcoinwallet.dat”
  • “C:UsersAll UsersAppDataRoamingBitcoinwallet.dat”
  • “C:UsersDefaultAppDataRoamingBitcoinwallet.dat”
  • “C:UsersPublicAppDataRoamingBitcoinwallet.dat”
  • “C:UsersXXXXXXAppDataRoamingBitcoinwallet.dat”
  • “C:UsersAll UsersAppDataRoamingBitcoinwallet.dat”

The malware then attempted to steal user credentials from a range of specific file transfer programs, including:

  • TurboFTP
  • FTPGetter
  • Estsoft
  • Ghisler Total Commander
  • COREFTP
  • LinasFTP
  • Robo-FTP 3.8
  • Robo-FTP 3.7
  • Far2 (Far manager)
  • BlazeFtp
  • 3D-FTP
  • Cyberduck
  • FlashFXP
  • BulletProof Software
  • GPSoftware
  • Background Intelligent Transfer Service
  • SiteDesigner
  • NetSarang

Following the failed attempt to steal credentials, another file was downloaded from the web. A large number of repetitive DNS queries were made to well-known websites including popular email servers.

If this was not enough abuse, a large number of emails were sent from the victim IP in a very short period of time.

If this was not enough abuse, a large number of emails were sent from the victim IP in a very short period of time. We observed up to 5 emails sent per second. The title of email was “Big News Released Yesterday”

The message in the SPAM message was:

I discovered the stock that big investors strive to add. Verde Science, Inc. (VR CI) is gaining active interest recently! The exposure just began the price could be exploding! Start VR CI on Tuesday October 13 under $0.13

The message of the SPAM makes indirect reference to the stock market. Strangely, the message did not have a link to follow.  We could assume that another message would be sent with the link?

It was only a matter of time for the victim IP to be blacklisted

It was only a matter of time for the victim IP to be blacklisted

The IP was then verified in Spamhaus and it was clearly blacklisted.

The IP was then verified in Spamhaus and it was clearly blacklisted.

Fortunately, a process to remove an IP that is blacklisted is not so difficult.

Fortunately, a process to remove an IP that is blacklisted is not so difficult.

The IP of the victim machine was successfully remove from the blacklist

The IP of the victim machine was successfully remove from the blacklist

CBL Removel

Recommendations:

Although the malware is not that sophisticated, it does remind us that basic hygiene around malware is vital. The 3 key takeaways from this are:

  1. Question all email links and attachments – period: Just because it arrived in your inbox, home or corporate account, does not mean that it’s legitimate. Although many detection systems are in place they are not infallible. Most malware when first created and used will evade detection at first. For example, at the time of analysis of this event, there was no entry in virus total.
  2. Do not click on suspicious attachments: Again, systems can be implement at a corporate level that will ‘sandbox’ or isolate attachments so they cannot steal or gain access to your core systems, but these may not be in place and must be configured correctly. Remain vigilant and question everything.
  3.  Remember – If you click, you can be owned.

If you do click or open something you think you may not have, make sure you know your companies Incident Response process and reporting structure. If there isn’t one, ask why not and what you should do if this occurs?

Malware Manual Unpacking – [Custom + UPX]

SHA-1: 1E6CF952D9F0D507A6AA98AD2B3327B83702BC17

Introduction

Implementing all sort of methods to bypass anti-virus (AV) scanners and/or to make the analysis of a malware sample a lot harder, at least from a static point of view, is an old dog’s trick.
At Nettitude, we see a lot of these techniques in evidence in malware that we come across during client engagements or that we personally collect via honeypots and other means.
Dealing with packers, either known or custom ones, is quite often an issue that any malware analyst has to deal with. Successfully unpacking and isolating the malware from the top protection layers can be really useful since it allows the analyst to concentrate only at the code that matters, and perform more detailed static analysis on the sample itself.

The custom layer

It doesn’t take much to realise that something is ‘wrong’ with this sample. Just by looking at the entry point of the module, an experienced eye will definitely blink.
Entry Point:

[cpp]
CALL 00401015
POP EBX
MOVD MM5, EBX
MOVD ECX, MM5
ADD ECX, 2C6
JMP ECX
[/cpp]

This jump takes us to a custom decryption code block. Not surprisingly, this is heavily obfuscated with a lot of junk instructions.

The following code block shows a few effective instructions surrounded by junk code.
For example, if you take a look at the first three instructions, the ‘ADD ECX,EBP’ instruction is a junk instruction. These three instructions can be re-written with just one: “MOV ECX,EDX”.

[cpp]
PUSH EDX
ADD ECX, EBP
POP ECX
MOV EAX, ECX
MOV CL, 0CA
XCHG CH, CH
ADD EBX, EAX
ADD EBX, DWORD PTR SS:[ESP]
AND ECX, D73E1285
LEA ECX, DWORD PTR DS:[E58CFC96]
MOV EAX, DWORD PTR DS:[EBX]
XOR ECX, EAX
CMP EDI, 0E2E4
JS 00401D4A
INC ECX
JO 00401D51
00401D4C BD 6149A0AD MOV EBP, ADA04961
MOV ECX, EDI
MOV EBP, EBP
IMUL EBP, EDI, CE86F98B
SUB EAX, ECX
BSWAP EBP
MOV CH, AL
MOV ECX, F7F0D4F3
MOV DWORD PTR DS:[EBX], EAX
MOV CL, 0CC
JE 00401D72
LEA ECX, DWORD PTR DS:[15F75C0D]
SBB CL, BH

[/cpp]

Once the custom decryption algorithm has finished its job, the execution will be transferred on the decrypted code block.
This stage of the custom packer acts as a loader. It will make use of a combination of CreateFileMapping/MapViewOfFile functions to allocate memory and copy there at the very same stage.
In the meantime, the authors didn’t forget to use some ‘funny’ names for the file mapping object: “Sessions1BaseNamedObjectspurity_control_7728”.
However, execution will never be transferred on that memory block and it will continue executing that stage from the original memory pages.
The next step is to create a new thread that will handle the final stage of this custom packing layer.

Thread entry point:

[cpp]
ENTER 0, 0
MOV EBP, DWORD PTR SS:[EBP+8]
CMP BYTE PTR SS:[EBP+402773], 1
JNZ 00402AF6
MOV ECX, DWORD PTR SS:[EBP+402774]
DEC ECX
TEST ECX, ECX
JE SHORT 00402A15
[/cpp]

This stage will finally make use of VirtualAlloc to copy the decrypted UPX-packed malware and pass execution to the entry point of the UPX packer.
However, there is a problem to solve at this stage. The execution is transferred out of the PE image memory range of the executable we are debugging. This can further confuse some unpacking tools since they will be trying to read information from the PE header of the original module in memory.
Even though there are techniques that an experienced unpacker can use to force those tools to read the information that they want, there are also cases like this one in which a simple trick can solve a big problem.

As already mentioned, the entire decrypted UPX-packed malware is now copied to another memory location. It is basically an entire PE file loaded in memory in the same way that would be if we had read the file from disk into a buffer.
So before proceeding into the next packing layer, we can easily dump and isolate the UPX-packed malware from memory so that we won’t have to deal with the first custom layer again.

Figure 1 - Memory Map

Figure 1 – Memory Map

Unpacking UPX

After we have dumped the UPX-packed malware from memory we can directly load this back to the debugger since it is basically a fully functional PE file. In summary, the custom packing layer is totally out of the game at this point.
Unpacking UPX is straight forward, and you can easily find a number of tutorials online that explain how it can be done, but since we are here let’s show this one more time.

UPX entry point:

[cpp]
PUSHAD
MOV ESI, 004AD000
LEA EDI, DWORD PTR DS:[ESI+FFF54000]
PUSH EDI
OR EBP, FFFFFFFF
JMP SHORT 004B7AE2
[/cpp]

The above code block is a common UPX entry point. Nothing really interesting here, apart from the fact that if you are familiar with UPX you can easily identify what you are dealing with.
Finding your way to the original entry point of the packed application is really easy. All you need to do is to scroll down the code until you find the following instructions.

Jmp to OEP:

[cpp]
POPAD
LEA EAX, DWORD PTR SS:[ESP-80]
PUSH 0
CMP ESP, EAX
JNZ SHORT 004B7C9C
SUB ESP, -80
JMP 00434567  JUMP to Original Entry Point. Place BP here and run.
[/cpp]

OEP:

[cpp]
PUSH EBP
MOV EBP, ESP
SUB ESP, 194
MOV DWORD PTR SS:[EBP-194], 0
PUSH 8002
CALL DWORD PTR DS:[40113C] ; kernel32.SetErrorMode
LEA EAX, DWORD PTR SS:[EBP-190]
PUSH EAX
PUSH 2
CALL DWORD PTR DS:[4011EC] ; WS2_32.WSAStartup
[/cpp]

In order to dump the unpacked PE file from memory we used the OllyDump plugin, but you can you can use others as well. However, if you use this one, remember to copy the RVA of the entry point (highlighted in the Figure 2) and also uncheck the ‘Rebuild Import’ since we will be using another tool to do so.

Figure 2 - OllyDump Plugin

Figure 2 – OllyDump Plugin

After we have saved the output in a file called ‘dump.pe’, we need to fix the imports table so that the dumped executable can load and run.
We will be using another tool, called Import REConstructor and in a few simple steps (Figure 3) we can have a fully functional and unpacked executable to start analysing.

Figure 3 - Import REConstructor

Figure 3 – Import REConstructor

Conclusion

Going through the process of manually unpacking and isolating the original malware from the top protection layers might not be something that you will always need to do in order to have an overview of what a malware sample is doing. However, when more detailed analysis is needed for sophisticated and complex malware, having the original executable isolated from all the packing layers might be a privilege rather than just a convenience. Keep in mind though, that some malware might check on runtime if they have been unpacked or modified.

 

To contact Nettitude’s editor, please email media@nettitude.com.

Vulnerability discovered in unsupported Cisco Systems VPN Client

Mitre assigned CVE-2015-7600

Introduction
An alternative, but no less accurate title to this article would be ‘why you shouldn’t stick with non-supported software’. On the 30th of July 2014, the widely used Cisco Systems VPN Client v5.x went out of support. Unfortunately announcing the end-of-life support for a software product doesn’t necessarily mean that whoever uses it will instantly migrate to the newer solution. This basically means that any computer host using such a product will forever be vulnerable to any newly discovered security holes in it.

Unfortunately for anyone still using the un-supported application, we have discovered a vulnerability in this software. Even though some issues can temporarily be addressed by an administrator, this should only be considered a lucky and temporary convenience, rather than a permanent solution to the problem. As more vulnerabilities like this are uncovered in an application that is not supported anymore by its vendor, these might give more access points to an attacker to compromise a corporate network.

The Vulnerability 

The ‘vpnclient.ini’ file keeps important configuration settings for the VPN Client, but allows any logged on user (Guest included) to write to that file. Since the VPN Client gives the option to setup an executable to run every time a user connects on a VPN server, and because this setting is stored inside the aforementioned ‘.ini’ file, a local attacker can set his own program to run which will be executed every time another user, such as an Administrator, uses the VPN Client. Executing this additional program can be totally transparent to the legitimate user. This setting can also be set from the ‘Options’ menu of the ‘vpngui.exe’ program and an example of the reflected changes in the ‘vpnclient.ini’ file would be:

Impact

Cisco Systems VPN Client is vulnerable to privilege escalation due to weak ACLs assigned to one of the files that store important configuration settings. This issue can allow a user from a limited account to perform actions that they are not authorised to do. Depending on who is using the VPN Client application, a local attacker can either execute code in the security context of another user with the same privileges, or with a user with higher privileges, such as an administrator.

Versions Affected

Nettitude tested this on the latest v5.x version (5.0.07.0440) that we managed to obtain for Windows 7 x64. However, earlier versions are quite likely affected by this issue.

Conclusion

As mentioned already, this product is not officially supported anymore and, for that reason, it is a fair decision of Cisco not to provide a patch for it. This is a typical example of an underlying issue for a fairly popular application only coming to light after it is not technically supported anymore. Hopefully this will raise some awareness and force some system administrators to think twice before they decide to stick with any non-supported applications, just because ‘they work’.

 

To contact Nettitude, please email media@nettitude.com.