Archive for September, 2013

Recently, we have observed a new backdoor family which we’ve called BLYPT. This family is called BLYPT because of its use of binary large objects (blob) stored in the registry, as well as encryption. Currently, this backdoor is installed using Java exploits; either drive-by downloads or compromised web sites may be used to deliver these exploits to user systems. Our research shows that the servers behind these attacks are mainly centered in Romania and Turkey.

Currently, this threat is primarily hitting users in the United States; however it seems that consumers (as opposed to businesses) are the most affected.

Arrival and Installation

In one case, we found a Java exploit that was used to spread this attack. This particular exploit, detected as JAVA_EXPLOYT.HI, can be used to run arbitrary code. It exploits a vulnerability, CVE-2013-1493, that has been exploited since February 2013. It was patched in March.

The exploit is used to download an installer (saved as ~tmp{random values}.tmp), which is responsible for downloading and installing the main BLYPT component onto the affected system. It is named logo32.png or logo64.png, depending on whether the user is running a 32-bit or 64-bit version of Windows, respectively. The installer attempts to connect to three servers every 3 seconds, until it successfully downloads the backdoor component. If it fails, it will retry up to 32 times before it gives up.

We have identified two BLYPT variants, which can be identified based on the file name used to save the main BLYPT component. In both cases, they are saved in the %App Data%\Microsoft\Crypto\RSA directory. One variant is saved as NTCRYPT{random values}.TPL; the second variant is saved as CERTV{random values}.TPL. Both variants have 32- and 64-bit versiosons, and their behavior is mostly identical. (We detect these variants as BKDR_BLYPT.A, BKDR_BLYPT.B and BKDR64_BLYPT.B.)

Figure 1. Infection diagram for BKDR_BLYPT

One difference between the two is where their C&C server information is stored. The NTCRYPT{random values}.TPL variants do not actually contain any C&C information on their own; the installer instead saves C&C information in the registry that the BLYPT backdoor uses. The CERTV{random values}.TPL variants have their C&C server information embedded in the file itself. In both cases, the C&C information is stored in the registry under the HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\CA\Certificates\
5A82739996ED9EBA18F1BBCDCCA62D2C1D670C\Blob key.

While the C&C server information is stored in the same key, their formatting is different. For the first variant, once decoded, the information is in plain text and in the following format:

Both variants encrypt their information using alleged (arc4) and use “http://microsoft.com” as the decryption key.

One more note about the installer: it provides instant feedback on the status of the install by accessing a URL on the malicious server, which actually serves as a status report. The URL would be: http://{malicious server}/index.aspx?info=<status keyword>. The status keyword can be any of the following:

startupkey_%d where %d = RegCreateKeyW return

reuse

configkey_%d where %d = RegCreateKeyA return

configkeyvalue_%d where %d = RegSetValueExA return

tserror_4_%d where %d = GetLastError from call to connect

createproc_%d where %d = GetLastError from call to CreateProcessW

reusereboot_%d_%d_%d

C&C Server Attribution

By decoding the configuration files used by this malware, we were able to determine the distribution of the C&C servers used by this threat, as seen in the chart below:

Figure 2. Location of BLYPT C&C Servers

Other Behavior

In addition to the C&C info mentioned earlier, BLYPT stores other information in the registry in the form of embedded “blobs”. These are as follows:

Table 1. Blobs used by BLYPT

As a backdoor, BLYPT also allows an attacker to send commands to an affected system. Among the commands than can be executed are:

Receive updated DLL binary

Receive updated configuration

Receive HTTP request commands, such as:

Send GET request to http://103.31.186.19:1000/FetchIP.aspx to retrieve public IP of affected machine

There are various reasons why targeted attacks can happen to almost any company. One of the biggest reasons is theft of a company’s proprietary information. There are many types of confidential data that could be valuable. Intellectual property is often the first thing that comes to mind. There are also other, less obvious items of value that can be acquired: for example financial information, employee and customer personal information, information related to pending sales, financial deals, and legal actions. However, companies can also be targeted for reasons having nothing to do with their products or information.

Targeted Attacks Serve as Launch Pads

Attackers may target a company so that they may use the newly compromised infrastructure as a launching ground for attacks against other organizations. In certain cases, the attackers may want to use the victim’s e-mail accounts to gain some legitimacy in a spear-phishing campaign.

Another reason for targeting may be who the company’s networks are connected to. A small vendor may supply parts to a larger integrator and this may require them to have access to the integrator’s networks. It may be easier and/or stealthier for the attacker to come in through the vendor’s network rather than try and gain a foothold in the integrator’s networks.

Additionally, a company may be targeted for the sole purpose of being used as a stepping stone or hop point to help obscure the path between the attacker and his target.

What Can Be Done to Deal with Targeted Attacks?

Unfortunately, time and the odds are on the side of the attacker. No matter how good a company’s defenses are, it takes just one configuration mistake or a single user to open a malicious file or visit an infected watering hole for the company to become infected. Once an attacker is inside a network, the goal must be to detect and contain them as quickly as possible. At that point, a full forensic investigation can be conducted to see where the attackers have been and what damage they have done.

So, is there anything that companies can do to deal with targeted attacks? The answer, is yes.

This process can be very time consuming, but there are two areas a company can address ahead of time to help minimize the damage, as well as make the investigation as quick and successful as possible. The first area involves changes to infrastructure –proper logging policies, network segmentation, tightening user security policies, and protecting critical data. The second area involves personnel. Companies should have their own threat intelligence group as well as a forensic team that is already trained and operational.

To help improve security posture, penetration testing can be a great help to companies. There is a lot to be learned from these tests, regardless whether they are required or not. At the very least, network testing should be done, but if possible allow social-engineering and physical security tests as well. Once completed, the penetration testing can be used as a training tool for the forensic team and provide lessons learned to the company regarding overall security issues.

Security as an Investment

There is a cost associated with these preparations, but they will be dwarfed by the cost of a single extensive targeted attack investigation. In addition to the actual amount to run the investigation, there are the harder to characterize costs including possible loss of contracts, investor confidence, or lawsuits. It is simply too expensive for companies to ignore the risks of being the victim of a targeted attack.

Recently, we spotted a new malware family that was being used in targeted attacks – the EvilGrab malware family. It is called EvilGrab due to its behavior of grabbing audio, video, and screenshots from affected machines. We detect EvilGrab under the following malware families:

BKDR_HGDER

BKDR_EVILOGE

BKDR_NVICM

Looking into the feedback provided by the Smart Protection Network, EvilGrab is most prevalent in the Asia-Pacific region, with governments being the dominant sector targeted. These are consistent with known trends in targeted attacks.

The most common arrival vector for EvilGrab malware is spear phishing messages with malicious Microsoft Office Attachments. In particular, malicious Word files and Excel spreadsheets that contain code that targets CVE-2012-0158 are a favored way to spread this new threat.

Information Theft

EvilGrab has three primary components: one .EXE file and two .DLL files. The .EXE file acts as the installer for all of the EvilGrab components. One of the .DLL files serves as a loader for the other .DLL file, which is the main backdoor component. Some variants of EvilGrab delete the .EXE file after installation to cover its tracks more effectively.

EvilGrab attempts to steal saved login credentials from both Internet Explorer and Outlook. The credentials of both websites and email accounts are targeted for theft by attackers.

In addition to this, it can also “grab” any played audio and/or video on the system using standard Windows APIs. As part of its backdoor functionality, it can also take screenshots and log keystrokes. All of these are uploaded to a remote server to be accessed by the attacker.

Targeted Applications

EvilGrab has some unique behaviors if it detects certain installed applications. First of all, it is explicitly designed to steal information from Tencent QQ, a Chinese instant messaging application. It steals and uploads all the memory used by QQ. This may be able to reveal the contents of conversations or the members of the user’s contacts list.

EvilGrab will attempt to inject itself into the processes of certain security products. In the absence of these security products, it will choose to inject itself into standard Windows system processes. ESET, Kaspersky, and McAfee have all been specifically targeted by EvilGrab for process injection.

Backdoor Activities

EvilGrab possesses backdoor capabilities that allows an attacker to carry out a wide variety of commands on the affected system. This grants them complete control over a system affected by EvilGrab.

As part of its command-and-control traffic, EvilGrab contains two separate identifiers, which may serve as campaign codes and/or trackers. One of the identifiers has been seen with the following values:

006

007

0401

072002

3k-Ja-0606

3k-jp01

4k-lyt25

88j

e-0924

LJ0626

RB0318

The other field has been seen with two values:

V2010-v16

V2010-v24

We have observed that the main backdoor component of those variants having the V2010-v24 identifier have a proper MZ/PE header. While most of those variants having the V2010-v16 identifier have some parts of their MZ/PE header overwritten with “JPEG” strings.

TDSS and ZeroAcess are both well-known threats that have many common characteristics. Both are difficult to remove rookits, both engage in click fraud and use peer-to-peer communication techniques. Some may even wonder if these similar threats come from the same group of cybercriminals.

In September 2012, researchers found several TDSS variants which were called “DGAv14″. These variants were distinguished by its use of randomly generated domains. However, we have identified interesting findings about these random domains, which suggest that they are also used by ZeroAccess.

Using Smart Protection Network feedback, we analyzed some interesting HTTP traffic, which we initially thought to be sent by TDSS DGAv14 versions. But upon closer examination, we found that this traffic was instead sent by ZeroAccess/SIREFEF variants.

This misidentification was due to this new TDSS variant’s use of the same domain as old versions of ZeroAccess. For example, on one particular day we identified this URL being used by ZeroAccess:

On the very same day, we found the following URL being used by a TDSS/DGAv14 variant:

http://{blocked domain}/{179-character encoded random string}

The domain names used in both cases was identical. In addition, the way both malware families make money (such as click fraud) remains the same.

In addition to the above connection, some newer ZeroAccess variants show other connections with TDSS. When we examine the traffic sent by both TDSS and these ZeroAccess variants, we find that they send information in similar ways. Both encode their traffic using base64 and pad this text with garbage characters at the beginning and end.

TDSS has traditionally used this method, but it seems that ZeroAccess has adapted this as well. However, this does not mean that ZeroAccess is now imitating TDSS. We believe that the domain generation algorithm module used by older ZeroAccess malware has now been adapted by TDSS specifically the DGAv14 variants.

However, key differences still exist between TDSS and ZeroAccess. Both still maintain separate P2P networks, with similar features but different implementation. In addition, ZeroAccess always infects COM objects and service.exe, whereas TDSS always infects the MBR. ZeroAccess will also disable TDSS on systems that the former infects.

The illustration below summarizes the relationships between TDSS and ZeroAccess:

Figure 1. ZeroAccess and TDSS relationships

In summary, we believe that there are now some ties between the TDSS and ZeroAccess families. This does not necessarily mean that the cybercriminals responsible are directly collaborating – the DGA module may have been acquired from a third party, and/or TDSS may be making money by hosting parts of ZeroAccess. We will continue to monitor and investigate these threats in order to protect our customers.

For more information on TDSS and ZeroAccess, please check our past posts below:

A week after September‘s Patch Tuesday, Microsoft rushed a “Fix It” workaround tool to address a new zero-day Internet Explorer vulnerability (CVE-2013-3893), which is reportedly being actively exploited in certain targeted attacks.

As Microsoft advised, the said exploit is targeting a Use After Free Vulnerability in IE’s HTML rendering engine (mshtml.dll). While current exploits are implemented entirely in JavaScript, an attacker can choose to use other methods like Java, Flash, VBScript, etc. as well. For more technical information about the vulnerability, one can check Microsoft’s blog post that describes the vulnerability in full detail.

Using this vulnerability, the attacker may corrupt the memory in such a way that could allow execution of arbitrary code with the rights of the logged-in user. To do so, an attacker must persuade its victim to browse an exploit-hosting website by way of phishing, spam or social networking sites. As per the Microsoft security advisory (2887505), all Internet Explorer versions (from version 6 to 11) are affected by this vulnerability.

Trend Micro Deep Security and Intrusion Defence Firewall (IDF) customers can use the following DPI rule to protect their hosts from attacks around (CVE-2013-3893):

Users are also advised to make use of Microsoft’s “Fix It” workaround tool and avoid visiting unverified links, websites or open any email messages from unknown/dubious senders. Other workarounds – like using non-IE browsers and avoiding running as an administrator account – should also be considered. We will update this blog once we have more information about this threat.