Category Archives: Malware Analysis

Malware Analysis – Dridex Loader – Part I

It has been quite some time since the article “Malware Analysis – Dridex & Process Hollowing” where we went over the analysis of banking trojan known as Dridex and how it leverages a technique known as process hollowing to extract an unpacked version of itself into memory. In that article, we briefly explained this technique and used OllyDbg to illustrate the different steps. Today, we will continue where we left off, extract the unpacked sample from memory and continue the analysis. This unpacked sample is known as the Loader. The Loader is what we will be looking at. We will mainly use a debugger to perform our analysis in order to understand more about what it does and get visibility into its functionality.  Please note that a bit of familiarity with OllyDbg is needed in order to follow the steps described.

You might want to read the last article and read more about the process hollowing technique in order to situate yourself before we start. As a refresher, the last step we did was to use OllyDbg to set a breakpoint on WriteProcessMemory() API and execute the binary. Once the breakpoint was reached we could see the moment before WriteProcessMemory() API was called and the different arguments in the stack.

In OllyDbg in the stack view (bottom right) we could see that one of the arguments is buffer. The data stored in this buffer is of particular interest to us because it contains the contents of the malicious code that is going to be written to the legitimate process i.e., the unpacked sample.

So, to continue our analysis we need to extract the unpacked sample into disk. We can perform this by saving contents of the buffer argument from the WriteProcessMemory() API into a file. In OllyDbg, in the memory view (bottom left) we right click – Backup – Save data to file and save the file with the suggested name _009C0000.mem.

dridex-unpackedsample

With the binary extracted we can, again. start the initial steps of malware analysis. As normal we perform basic static analysis in 3 steps. The first step is to profile the file. We can easily determine its an PE32 executable file using the Linux “file” command. In addition, we compute the MD5 of the file which is c2955759f3edea2111436a12811440e1. With this fingerprint we can search different online tools such as VirusTotal in order to find further information about it.

Second step is to run the strings command against the binary. The strings command will display printable ASCII and UNICODE strings that are embedded within the file. This can disclose information about the binary functionality.

The third step is to use some tool like the PE Analysis Toolkit from Fernando Mercês or CFF explorer from Daniel Pisteli to analyze the Win32 PE headers. Extracting information from the PE headers can reveal information about API calls that are imported and exported by the program. It can also disclose date and time of the compilation and other embedded data of interest. The binary contains library dependencies and these dependencies can be looked at in order to infer functionality through static analysis. These dependencies are included in the Import Address Table (IAT) section of the PE structure so the Windows loader (ntdll.dll) can know which dll’s and functions are needed for the binary to properly run.

Noteworthy, is that in this binary, the PE headers don’t contain an Import Directory and we are unable to determine its dependencies because the IAT is missing. This makes this binary more stealthier and more complex to analyze. As result we will need to load this sample into OllyDbg and try to find out more information about it while stepping throughout the code. The binary needs to somehow resolve the Imports.

Dridex is known to use different techniques to encode and obfuscate data.  This sample is no different. We open the _009C0000.mem file into OllyDbg and while going back and forth and stepping into the different functions, we can observe that in the beginning of the execution there is a XOR function that is performed. By following the memory addresses that are used across the different function arguments from the different routines, and looking in detail into the memory and stack pane we can see that the names of the different API calls start to appear. There is a function at virtual address 0x00406c0f  that performs XOR of a chunk of data stored at virtual address 0x0040f060. It uses 2 XOR 32-bits keys. In the picture below you can see in the dissasembler window (top left) the instruction that loads the first XOR key into the register EAX. By following the function loop and see the content of the memory addresses we would be able to see that LoadLibraryA() API appears as string.

Because going over the loop in OllyDbg and observe the API calls being resolved is a tedious process we can perform the decoding offline. We know where the chunk of data starts and the XOR keys. So, we can save the chunk of data into a file in order to perform the decoding and get all the data. To do this in OllyDbg, we set a breakpoint in the XOR function at virtual address 0x00406c0f, In the dissasembler window (top left), Ctrl + G and in the expression to follow dialog box enter the function address. Then press F2 to set a breakpoint in that line. Then hit F9 to run the sample. It will pause the execution when the breakpoint is hit. Then press F7 to step into each instruction until you hit the function that loads the first XOR key at address 0x00406c36. Then go into to the Memory dump window (Bottom left corner), hit Ctrl + G and insert the memory address 0x0040f060. Then select the data until you see a series of null bytes. Right click and choose Binary – Binary Copy. Below a print screen of this step.

dridex-xor-imports

Then we can paste the data to a text file and use a small python script to perform the XOR decoding using the obtained keys and see that the binary has an extensive list of 355 imported functions.

dridex-importsdecoding

This was the first XOR operation. Then after decoding the API it needs, the binary decodes the chunk of data stored at 0x00414c20 and gets the names of the libraries like kernel32.dll, ntdll.dll and others.  This operation is performed by a function stored at Virtual Address 0x0040d42f. In the picture below you can see in the dissasembler window (top left) the instruction that loads the first XOR key into the register EAX.

dridex-xor-libraries

Using the same technique has previously described, we can save this chunk of data into a file and perform the XOR decoding in order to get the list of libraries that are used by the binary.

dridex-librariesdecoding

The strings decoding happens throughout the execution. There are 5 chunks of data that are decoded using XOR and 2 x 32-bits keys. The below table shows the XOR keys and the offset address of the data and functions that are called in order to decode the strings:

dridex-datachunks

By decoding all the chunks we get visibility into the binary functionality and can deduce its malicious intent. For the sake of brevity and because the list of strings is quite extensive, this is left as exercise to the reader. Nonetheless, below is a small portion of the decoded strings. These ones are associated with the UAC bypass technique used by Dridex to get Admin rights.

dridex-strings

That’s it for part 1. On part 2 we will look into how the C&C addresses are obtained and some of the techniques used by Dridex to generate the XML messages used by the loader.

Sample MD5: c2955759f3edea2111436a12811440e1

References:

http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/dridex-financial-trojan.pdf

https://www.cert.pl/news/single/talking-dridex-part-0-inside-the-dropper/

http://christophe.rieunier.name/securite/Dridex/20150608_dropper/Dridex_dropper_analysis.php

https://www.virusbulletin.com/virusbulletin/2015/07/dridex-wild/

https://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2015-01/SAR-PR-2015-01_.pdf

https://cdn2.hubspot.net/hubfs/507516/ANB_MIR_Dridex_PRv7_final.pdf

https://www.lexsi.com/securityhub/how-dridex-stores-its-configuration-in-registry/?lang=en

http://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html

https://www.blueliv.com/downloads/documentation/reports/Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf

 

Tagged , , ,

Unleashing YARA – Part 3

yara-logoIn the second post of this series we introduced an incident response challenge based on the static analysis of a suspicious executable file. The challenge featured 6 indicators that needed to be extracted from the analysis in order to create a YARA rule to match the suspicious file. In part 3 we will step through YARA’s PE, Hash and Math modules functions and how they can help you to meet the challenge objectives. Lets recap the challenge objectives and map it with the indicators we extracted from static analysis:

  1. a suspicious string that seems to be related with debug information
    • dddd.pdb
  2. the MD5 hash of the .text section
    • 2a7865468f9de73a531f0ce00750ed17
  3. the .rsrc section with high entropy
    • .rsrc entropy is 7.98
  4. the symbol GetTickCount import
    • Kernel32.dll GetTickCount is present in the IAT
  5. the rich signature XOR key
    • 2290058151
  6. must be a Windows executable file
    • 0x4D5A (MZ) found at file offset zero

In part 2 we created a YARA rule file named rule.yar, with the following content:

import "pe"

If you remember the exercise, we needed the PE module in order to parse the sample and extract the Rich signature XOR key. We will use this rule file to develop the remaining code.

The debug information string

In part 1 I have introduced YARA along with the rule format, featuring the strings and condition sections. When you add the dddd.pdb string condition the rule code should be something like:

yara_3_1

The code above depicts a simple rule object made of a single string variable named $str01 with the value set to the debug string we found.

The section hash condition

Next item to be added to the condition is the .text section hash, using both PE and HASH modules. To do so we will iterate over the PE file sections using two PE module functions: the number_of_sections and sections. The former will be used to iterate over the PE sections, the latter will allow us to fetch section raw_data_offset, or file offset, and raw_data_size, that will be passed as arguments to md5 hash function, in order to compute the md5 hash of the section data:

yara_3_2

The condition expression now features the for operator comprising two conditions: the section md5 hash and the section name. In essence, YARA will loop through every PE section until it finds a match on the section hash and name.

The resource entropy value

Its now time to add the resource entropy condition. To do so, we will rely on the math module, which will allow us to calculate the entropy of a given size of bytes. Again we will need to iterate over the PE sections using two conditions: the section entropy and the section name (.rsrc):

yara_3_3

Again we will loop until we find a match, that is a section named .rsrc with entropy above or equal to 7.0. Remember that entropy minimum value is 0.0 and maximum is 8.0, therefore 7.0 is considered high entropy and is frequently associated with packing [1]. Bear in mind that compressed data like images and other types of media can display high entropy, which might result in some false positives [2].

The GetTickCount import

Lets continue improving our YARA rule by adding the GetTickCount import to the condition. For this purpose lets use the PE module imports function that will take two arguments: the library and the DLL name. The GetTickCount function is exported by Kernel32.DLL, so when we passe these arguments to the pe.imports function the rule condition becomes:

yara_3_4

Please note that the DLL name is case insensitive [3].

The XOR key

Our YARA rule is almost complete, we now need to add the rich signature key to the condition. In this particular case the PE module provides the rich_signature function which allow us to match various attributes of the rich signature, in this case the key. The key will be de decimal value of dword used to encode the contents with XOR:

yara_3_5

Remember that the XOR key can be obtained either by inspecting the file with a hexdump of the PE header or using YARA PE module parsing capabilities, detailed in part 2 of this series.

The PE file type

Ok, we are almost done. The last condition will ensure that the file is a portable executable file. In part two of this series we did a quick hex dump of the samples header, which revealed the MZ (ASCII) at file offset zero, a common file signature for PE files. We will use the YARA int## functions to access data at a given position. The int## functions read 8, 16 and 32 bits signed integers, whereas the uint## reads unsigned integers. Both 16 and 32 bits are considered to be little-endian, for big-endian use int##be or uint##be.

Since checking only the first two bytes of the file can lead to false positives we can use a little trick to ensure the file is a PE, by looking for particular PE header values. Specifically we will check for the IMAGE_NT_HEADER Signature member, a dword with value “PE\0\0”. Since the signature file offset is variable we will need to rely on the IMAGE_DOS_HEADER e_lfanew field. e_lfanew value is the 4 byte physical offset of the PE Signature and its located at physical offset 0x3C [4].

With the conditions “MZ” and “PE\0\0” and respective offsets we will use uint16 and uint32 respectively:

yara_3_6

Note how we use the e_lfanew value to pivot the PE Signature, the first uint32 function output, the 0x3C offset, is used as argument in the second uint32 function, which must match the expected value “PE\0\0”.

Conclusion

Ok! We are done, last step is to test the rule against the file using the YARA tool and our brand new rule file rule.yar:

yara_3_7

YARA scans the file and, as expected, outputs the rule matched rule ID, in our case malware001.

A final word on YARA performance

While YARA performance might be of little importance if you are scanning a dozen of files, poorly written rules can impact significantly when scanning thousands or millions of files. As a rule of thumb you are advised to avoid using regex statements. Additionally you should ensure that false conditions appear first in the rules condition, this feature is named short-circuit evaluation and it was introduced in YARA 3.4.0 [5]. So how can we improve the rule we just created, in order to leverage YARA performance? In this case we can move the last condition, the PE file check signature, to the top of the statement, by doing so we will avoid checking for the PE header conditions if the file is an executable (i.e. PDF, DOC, etc). Lets see how the new rule looks like:

yara_3_8

If you like to learn more about YARA performance, check the Yara performance guidelines by Florian Roth, as it features lots of tips to keep your YARA rules resource friendly.

References

  1. Structural Entropy Analysis for Automated Malware Classification
  2. Practical Malware Analysis, The Hands-On Guide to Dissecting Malicious Software, Page 283.
  3. YARA Documentation v.3.4.0, PE Module
  4. The Portable Executable File Format
  5. YARA 3.4.0 Release notes
Tagged , ,

Retefe Banking Trojan

mtanBack in 2014, Retefe banking trojan started to appear in the news. First appearance in public was in a blog post from the Microsoft Threat Research & Response team. Then in July 2014, David Sancho from Trend Micro wrote the first public report about it. A video from Botconf about this research is also available here. Following that a great write-up by Daniel Stirnimann from SWITCH-CERT is here and here. Time as passed and the threat actors behind Retefe continue to evolve and adopt new techniques to  commit fraud.

In the past, Retefe has maintained a low profile when compared with other Banking trojans. It is known to target users in Sweden, Austria, Switzerland and Japan. Retefe is an interesting banking trojan because is designed to bypass the two-factor authentication scheme (mTAN) used by different banks by encouraging the victims to install a fake app. mTANs (Mobile Transaction Authentication Number) are used by banks as a second factor authentication. When the user tries to login to the bank or perform a transaction a SMS is sent to the user’s mobile phone. Retefe is then able to hijack the SMS’s.

The threat actors behind the Retefe malware use phishing emails as main infection vector. The emails are tailored to match the country that they are targeting. In Switzerland for example, the lures take advantage of social engineering techniques by impersonating institutions like Zalando and Ricardo to trick the users into executing the malware. One recent phishing campaign contained a ZIP with a malicious executable inside (SHA1 : 32ed8fb57e914d4f906e52328156f0e457d86761). The image below illustrates one of these emails. The sender falsely mimics a legitimate business transaction from Zalando.

retefe-phishing

When installed, the Retefe Trojan adds a self-signed certificate authority (CA) root certificate to the victim’s browser certificate store. In this version the operation occurs in memory and the certificate is written to the Registry Key HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\Certificates\<random number> where random number matches the Thumbprint of the certificate. This technique allows the threat actor to perform man-in-the-middle attacks and intercept or modify information from the banking site. The below picture shows the self signed certificate used in this campaign.

retefe-fakecert

At execution the first request is a HTTP request to checkip.dyndns.com or icanhazip.com in order to determine the victim public IP address. Interesting the request does not have an User-Agent. The IP addresses value returned is then used to append to another request which is used to retrieve the Proxy PAC config  that is written to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL setting in the registry. This setting modifies the victim browser Proxy-PAC setting that allows the traffic to be redirected to a malicious proxy server.

retefe-proxypacreg

The Proxy-PAC configuration in this campaign is retrieved from different TOR websites. The code is a slightly obfuscated JavaScript. The picture below shows the answer received from the TOR website. The answer is tailored based on the IP address of the victim . In this case the payload being delivered is targeted to Switzerland.

retefe-requestproxypac

After deobfuscation we can see the hosts that are being targeted. With this configuration all the traffic that matches the targeted Swiss Banks will be redirected to a SOCKS proxy which is hosted in Russia. The redirection only occurs if it meets the conditions from the Proxy-PAC file. Otherwise the traffic is forwarded without the use of the SOCKS proxy. When browsing the internet, if the traffic matches one of the hosts defined in the Proxy-PAC configuration file then the traffic gets redirected to the SOCKS proxy. This will allows the threat actors to intercept and modify all traffic at will. When browsing to the login page of one of the banks targeted in this campaign, the victim lands on a phishing page that mimics the bank web site and prompts the user with a pop-up message. This message attempts to lure the users that the appearance of the online banking site has been renewed and new features are waiting to be discovered!

retefe-cslogin

After clicking OK the user is prompted to enter his credentials. Then the user is presented with a pop-up message asking him to wait – behind the scenes the credentials are sent to the threat actor.  The user is then prompted to confirm what type of second factor authentication he currently uses. He can choose SMS or RSA token as second factor authentication. Following the selection of SMS as second factor authentication the user is asked about his mobile phone number and mobile operating system.

retefe-csmtan

Current version of Retefe only targets Android phones. After entering a mobile phone, the user will be prompted to install a new banking mobile application. The victim will receive a SMS on his mobile phone asking to install the new APK. The APK is hosted on a site owned by the threat actors. One example of an APK is CreditSuisse-Security-v-07_02 1.apk (sha1: 4bdc5ccd3e6aa70b3e601e1b4b23beaf09f33d7a).  If for some reason the victim does not receive the SMS, then a screen is shown in order to encourage the installation of it using a QR code.

retefe-cscode

Installing the Android app allows the attacker to gain full control over the victims phone and among other things hijack the SMS’s sent by the Bank and take control over the users online banking session. The picture below illustrates the initial setup screen of the APK installation.

maliciousapkinst3

The code, functionality and the C&C protocol of the APK has been researched extensively by Angel Alonso-Párrizas in a series of articles including herehere and here. The APK is an adaptation of the Signal Android APK (a.k.a. Text Secure) from Moxie Marlinspike.  Among other features allows one to store and send encrypted text messages.  The figure below shows some of the permissions that are granted to this malicious APK.

maliciousapkinst5

In this case the threat actors reused the code from Signal Android to implement the the  Command and control (C2) communication. The traffic uses the Blowfish symmetric algorithm. It communicates with a primary C2 and if it fails it tries a backup address. The C2 addresses are stored in file named config.cfg which can be found in the decompiled APK. The data stored in the config.cfg and the traffic can be decrypted with Blowfish in CBC chaining mode. The key and IV used is also stored in the APK. The picture below shows the decrypted configuration file which contains the addresses of two compromised servers that are used to then communicate to the Retefe backend.

retefe-apkconfig

As soon as the APK is installed and launched it starts beaconing out to the C2 address. The C2 traffic is encrypted using the Blowfish encryption algorithm, and the traffic uses HTTP.

retefe-apkcnctraffic

The encrypted information contains details about the victim’s mobile device, including the SIM country, operator, serial number, IMEI, phone number, model and brand. The below figure shows the decrypted traffic. In this decrypted traffic there is a block of base64 data which decoded will give the mobile device information.

retefe-trafficdecoded

Meanwhile, in the banking session the user is asked to enter the OTP (One Time Password) code seen in the fake mobile app. From this moment onward the threat actors are in possession of the username, password and mTAN which allow them to commit fraudulent payments. In addition they have control over the victims mobile phone and can send real-time instructions via SMS. See Angel’s article here and TrendMicro here about the different SMS C2 commands.

This particular malware can be identified by the home users when they are browsing to the Banking website because it breaks the EV SSL certificate seen in the browsers. This does not occur with other types of banking malware. The Counter Threat Unit from Dell SecureWorks just recently released the “Banking Botnets: The Battle Continues” article that contains about the top banking malware seen in 2015.

Moving from the traditional internet banking to a more mobile experience is a fast growing trend. This will fuel the adoption of new techniques by the threat actors in order to leverage the digital channels to commit fraud. Banking trojans are sophisticated threats that leverage technology and social engineering and are here to stay!

Phishing campaigns that distribute banking malware are common and ongoing problem for end users and corporations.E-mail continues to be the weapon of choice   for mass delivering malware. The tools and techniques used by attackers  continue to evolve and bypass the security controls in place. From a defense perspective, the US-CERT put together excellent tips for detecting and preventing this type of malware and to avoid scams and phishing attempts applicable to home users and corporations.

 

 

Tagged , , ,

Unleashing YARA – Part 2

yarapart2In the first post of this series we uncovered YARA and demonstrated couple of use case that that can be used to justify the integration of this tool throughout the enterprise Incident Response life-cycle. In this post  we will step through the requirements for the development of YARA rules specially crafted to match patterns in Windows portable executable “PE” files. Additionally, we will learn how to take advantage of Yara modules in order to create simple but effective rules. Everything will be wrapped-up in a use case where an incident responder, that will be you, will create YARA rules based on the static analysis of a PE file.

Specifically, the use case scenario will be split into two posts. In part 2 we will start with an incident report that will introduce a simple rule development challenge, solely based on static analysis. In the part 3,  will cover rule creation, performance tuning and troubleshooting.

Prerequisites

Before we begin you will need a Linux distribution with the following tools:

If you are in a hurry I advise you to pick REMnux, Lenny Zeltser’s popular Linux distro for malware analysis, which include a generous amount of tools and frameworks used in the dark art of malware analysis and reverse engineering. REMnux is available for download here.

Additionally you will need a piece of malware to analyse, you can get your own copy of the sample from Malwr.com:

Malwr.com report link here

Sample MD5: f38b0f94694ae861175436fcb3981061

WARNING: this is real malware, ensure you will do your analysis in a controlled, isolated and safe environment, like a temporary virtual machine.

Incident Report

Its Wednesday 4:00PM when a incident report notification email drops on your mailbox. It seems that a Network IPS signature was triggered by a suspicious HTTP file download (f38b0f94694ae861175436fcb3981061) hash of a file. You check the details of the IPS alert to see if it stored the sample in a temporary repository for in-depth analysis. You find that the file was successfully stored and its of type PE (executable file), definitely deserves to be look at. After downloading the file you do the usual initial static analysis: Google for the MD5, lookup the hash in Virustotal, analyse the PE header of the file looking for malicious intent. Right of the bat the sample provides a handful of indicators that will help you to understanding how the file will behave during execution. Just what you needed to start developing your own YARA rules.

The challenge

Create a YARA rule that matches the following conditions:

  1. a suspicious string that seems to be related with debug information
  2. the MD5 hash of the .text section
  3. the .rsrc section with high entropy
  4. the symbol GetTickCount import
  5. the rich signature XOR key
  6. must be a Windows executable file

Static Analysis

Before we continue let me write that the details concerning the structure of the PE file are omitted for the sake of brevity. Please see here and here for more information on PE header structure. Onward!

The first challenge is to find a string related with debug information left by the linker [1], specifically we will be looking for a program database file path (i.e. PDB). Lets  run the strings command to output the ASCII strings:

yara_2.1_1

strings output

Amid the vast output the dddd.pdb string stands out. This is probably what we are looking for. Note that is important to output the file offset in decimal with -t d suffix so that you can pinpoint the string location within the file structure. If the string is indeed related to debug information it should be part of the RSDS header. Let’s dump a few bytes of the sample using the 99136 offset as a pivot:

yara_2.1_2

xxd output

The presence of RSDS string gives us the confidence to select the string dddd.pdb as the string related to the debug information.

Next we need to compute the hash of the .text section, that typically contains the executable code [2], for this task we will use hiddenillusion’s version of pescanner.py [3] using the sample name as argument:

yara_2.1_3

pescanner.py initial report

yara_2.1_4

pescanner.py report on sections, resources and imports on the PE file

pescanner.py outputs an extensive report about the PE header structure, on which it includes the list of sections along with the hash. Take note of the .text section MD5 hash (2a7865468f9de73a531f0ce00750ed17) as we will need to use it later when creating the YARA rule.

Also in the pescanner.py report we are informed that the .rsrc section as high entropy. This is a suspicious indicator for the presence of heavily obfuscated code. Please keep this in mind when creating the rule, as this info will help us answering the third item in the challenge. Lastly the report also features the list of imported symbols, in which we can see the presence of GetTickCount, a well known anti-debugging timing function [4]. This will be required to answer the fourth entry of the challenge. By the way, the report also mentions the file type, indicating we are in the presence of a PE32 file, which matches the sixth item of the challenge.

Lastly we need to get our hands on the XOR key used to encode the Rich signature, read more about the Rich signature here. You can check existence of this key in two ways: traditionally you would dump the first bytes of the sample, enough to cover all the DOS Header in the PE file, the Rich signature starts at file offset 0x80, and the XOR key will be located in the dword that follows the Rich ASCII string:

yara_2.1_5

Bear in mind that the x86 byte-order is little-endian [5], therefore you need to byte-swap the dword value, so the XOR key value is 0x887f83a7 or 2290058151 in decimal.

Now for the easy way. Remember when I have mentioned in the first post of this series that the YARA scan engine is modular and feature rich? This is because you can use YARA pretty much like pescanner.py, in order to obtain valuable information on the PE header structure. Let’s start by creating the YARA rule file named rule.yar with the following content:

 import “pe”

Next execute YARA as follows:

yara_2.1_6

strings command output

By using the –print-module-data argument YARA will output the report of the PE module, on which will include the rich_signature section along with the XOR key decimal value.

Ok, we now have gathered all the info required  to start creating the YARA rule and finish the challenge. In the part 3 of this series, we will cover the YARA rule creation process, featuring the information gathered from static analysis. Stay tuned!

References

  1. http://www.godevtool.com/Other/pdb.htm
  2. Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software, (page 22)
  3. https://github.com/hiddenillusion/AnalyzePE/blob/master/pescanner.py
  4. http://antukh.com/blog/2015/01/19/malware-techniques-cheat-sheet
  5. http://teaching.idallen.com/cst8281/10w/notes/110_byte_order_endian.html
Tagged , , ,

Exploit Kit Turf Wars

A rare event when two different Exploit Kits are disputing victims’ over the same territory. The threat actors behind the EK’s are finding vulnerable websites in order to host their malicious JavaScript code globally in a repeatable and automated fashion [13][14]. By a twist of fate a legitimate web server was turned into a mechanism to deliver malicious code by two of the most popular EK’s. An unfortunate but remarkable event where one can observe the confrontation between the challenger Neutrino Exploit Kit [10][11] and the infamous Angler Exploit Kit [2][3][7] in a fierce competition.

Once a user visits the compromised site the user is redirected to both the Neutrino and Angler EK landing pages. Both exploit kits enforce sophisticated capabilities that evade detection, thwart analysis and deliver reliable exploits [19]. First, the client IP address is profiled in order to filter out systems that do not meet the requirements. Then it follows a series of events with the goal to find un-patched browsers and applications that permit the EK to exploit client side vulnerabilities to deliver a malicious payload. On one hand the Neutrino facilitates the delivery of the Locky ransomware. On the other hand Angler facilitates the delivery of the TeslaCrypt ransomware.

Both EK’s follow the same strategy – Deliver malicious Adobe Flash files that act as facilitator to carry different exploits.  In this particular case, Neutrino is the first to be executed. When the user gets redirected to the landing page a small HTML page with an object tag defined in its body is delivered. This object tag directs the browser to load the first stage Flash file [1]. The first stage Flash file is then loaded and a decryption routine occurs at runtime that loads another Flash file. This file is used as wrapper for the multiple exploits and contains ActionScript3 code that verifies if the properties of the system environment are the right ones. The below picture shows the decompiled ActionScript3 code of the second stage Flash file. On the right side the different environmental checks performed by code.

neutrino-secondstagetw

If the conditions are met then the environment is fingerprinted in order to determine which vulnerability to exploit. On the left side of the above picture you can see the different wrappers that contains 5 different exploits. Then is a matter of code execution. In the below picture we can see Neutrino exploiting CVE-2015-0016 and invoking wscript.exe to download an encrypted payload which in this case is the new ransomware called Locky [16][17].

neutrino-tswbprx

Meanwhile, Angler delivers obfuscated JavaScript code combined with HTML tags that is blended with the main page of the compromised site. After several layers of obfuscation the result is a JavaScript function that stores a cookie and makes the browser process a HTML <iframe> tag. This triggers the browser to make a request to the Angler landing page which has a remarkable thumbprint. Among the malicious and heavily obfuscated JavaScript code you have passages from Jane Austen’s Sense and Sensibility book [8][12]. The picture below shows these passages in the traffic stream.

angler-landingpage

Following that, the malicious code verifies the presence of different antivirus and virtualization software [17]. If any of the checks perform return positive then the code will stop the infection process. If that is not the case a malicious Adobe Flash file is downloaded. Just like Neutrino, the malicious Adobe Flash file acts as a facilitator. The first stage Flash file is loaded and a decryption routine occurs at runtime that loads another Flash file. This file is used as wrapper for the multiple exploits that Angler supports [4][5][18][20]. If the victim system is vulnerable then the exploit code is executed and shellcode will instruct the operating system to download the malware in an encrypted fashion. The payload is then, decrypted and launched [6][9]. Angler has the particularity to allow fileless infections which means the malicious code is never written to disk and stays in memory. This makes it difficult to detect and analyse. When the malicious payload is launched the victim will be promted with UAC dialog box if does not have admin rights asking for the Administrator password. If the password is entered, the executable is launched and the system gets infected with TeslaCrypt.

In this head to head battle for resources and against the infamous Angler, Neutrino seems to be faster and wins! As illustrated in the below picture when Angler is prompting the user for admin credentials Neutrino already infected the system and display the new locky ransom note (see behind the UAC prompt).

angler-uac

For security enthusiasts, I uploaded the ExploitKitTurfWars.pcap file to Virus Total. This will allow one to practice and improve their ability to determine the actions which have taken place and understand all kinds of artifacts which occur within this interesting scenario. Might be interesting to find why in this case Neutrino is more effective. Practice these kind of skills and share your experiences!

Against these sophisticated threats there is no silver bullet. General mitigations against malware threats are provided by US-CERT here. Because Exploit Kits rely heavily on client side exploits, it is important to keep browsers, operating systems and applications updated. In addition, for home users the usage of Microsoft EMET and non-admin account is a must.

 

 

References:
[1] https://www.trustwave.com/Resources/SpiderLabs-Blog/Neutrino-Exploit-Kit-–-One-Flash-File-to-Rule-Them-All/
[2] http://www.talosintel.com/angler-exposed/
[3] https://blogs.sophos.com/2015/07/21/a-closer-look-at-the-angler-exploit-kit/
[4] http://community.websense.com/blogs/securitylabs/archive/2015/02/05/angler-exploit-kit-operating-at-the-cutting-edge.aspx
[5] http://www.fuzzysecurity.com/tutorials/22.html
[6] https://sentrant.com/2015/05/12/briefing-angler-exploit-kit/
[7] http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
[8] http://blog.checkpoint.com/2015/02/20/494/
[9] https://hiddencodes.wordpress.com/2014/10/01/digging-deep-into-angler-fileless-exploit-delivery-2/
[10] http://malware.dontneedcoffee.com/2014/11/neutrino-come-back.html
[11] http://malware.dontneedcoffee.com/2013/03/hello-neutrino-just-one-more-exploit-kit.html
[12] http://www.gutenberg.org/files/161/161-h/161-h.htm
[13] http://researchcenter.paloaltonetworks.com/2016/01/angler-exploit-kit-continues-to-evade-detection-over-90000-websites-compromised/
[14] http://research.zscaler.com/2015/08/neutrino-campaign-leveraging-wordpress.html
[15] https://twitter.com/antonivanovm/status/684823229177950208
[16] http://www.malware-traffic-analysis.net/2016/02/12/index.html
[17] https://blog.malwarebytes.org/exploits-2/2015/05/exploit-kit-authors-give-up-on-malwarebytes-users/
[18] http://malware.dontneedcoffee.com/2016/01/cve-2015-8651.html
[19] http://researchcenter.paloaltonetworks.com/2015/06/understanding-flash-exploitation-and-the-alleged-cve-2015-0359-exploit/
[20] http://hooked-on-mnemonics.blogspot.ch/2015/06/base91-angler-swfs.html

 

Tagged , , ,

Unleashing YARA – Part 1

[Editor’s Note: In the article below, Ricardo Dias who is a SANS GCFA gold certified and a seasoned security professional demonstrates the usefulness of Yara – the Swiss Army knife for Incident Responders. This way you can get familiar with this versatile tool and develop more proactive and mature response practices against threats. ~Luis]

Intro

yara_logoI remember back in 2011 when I’ve first used YARA. I was working as a security analyst on an incident response (IR) team, doing a lot of intrusion detection, forensics and malware analysis. YARA joined the tool set of the team with the purpose to enhance preliminary malware static analysis of portable executable (PE) files. Details from the PE header, imports and strings derived from the analysis resulted in YARA rules and shared within the team. It was considerably faster to check new malware samples against the rule repository when compared to lookup analysis reports. Back then concepts like the kill chain, indicator of compromise (IOC) and threat intelligence where still at its dawn.

In short YARA is an open-source tool capable of searching for strings inside files (1). The tool features a small but powerful command line scanning engine, written in pure C, optimized for speed. The engine is multi-platform, running on Windows, Linux and MacOS X. The tool also features a Python extension providing access to the engine via python scripts. Last but not least the engine is also capable of scanning running processes. YARA rules resemble C code, generally composed of two sections: the strings definition and a, mandatory, boolean expression (condition). Rules can be expressed as shown:

rule evil_executable
{
    strings:
        $ascii_01 = "mozart.pdb"
        $byte_01  = { 44 65 6d 6f 63 72 61 63 79 }
    condition:
        uint16(0) == 0x5A4D and
        1 of ( $ascii_01, $byte_01 )
}

The lexical simplicity of a rule and its boolean logic makes it a perfect IOC. In fact ever since 2011 the number of security vendors supporting YARA rules is increasing, meaning that the tool is no longer limited to the analyst laptop. It is now featured in malware sandboxes, honey-clients, forensic tools and network security appliances (2). Moreover, with the growing security community adopting YARA format to share IOCs, one can easily foresee a wider adoption of the format in the cyber defence arena.

In the meantime YARA became a feature rich scanner, particularly with the integration of modules. In essence modules enable very fine grained scanning while maintaining the rule readability. For example the PE module, specially crafted for handling Windows executable files, one can create a rule that will match a given PE section name. Similarly, the Hash module allows the creation on hashes (i.e. MD5) based on portions of a file, say for example a section of a PE file.

YARA in the incident response team

So how does exactly a tool like YARA integrate in the incident response team? Perhaps the most obvious answer is to develop and use YARA rules when performing malware static analysis, after all this is when the binary file is dissected, disassembled and understood. This gives you the chance to cross-reference the sample with previous analysis, thus saving time in case of a positive match, and creating new rules with the details extracted from the analysis. While there is nothing wrong with this approach, it is still focused on a very specific stage of the incident response. Moreover, if you don’t perform malware analysis you might end up opting to rule out YARA from your tool set.

Lets look at the SPAM analysis use case. If your team analyses suspicious email messages as part of their IR process, there is great chance for you to stumble across documents featuring malicious macros or websites redirecting to exploit kits. A popular tool to analyse suspicious Microsoft Office documents Tools is olevba.py, part of the oletools package (3), it features YARA when parsing OLE embedded objects in order to identify malware campaigns (read more about it here). When dealing with exploit kits, thug (4), a popular low-interaction honey-client that emulates a web browser, also features YARA for exploit kit family identification. In both cases YARA rule interchanging between the IR teams greatly enhances both triage and analysis of SPAM.

Another use case worth mentioning is forensics. Volatility, a popular memory forensics tool, supports YARA scanning (5) in order to pinpoint suspicious artefacts like processes, files, registry keys or mutexes. Traditionally YARA rules created to parse memory file objects benefit from a wider range of observables when compared to a static file rules, which need to deal with packers and cryptors. On the network forensics counterpart, yaraPcap (6), uses YARA for scan network captures (PCAP) files. Like in the SPAM analysis use case, forensic analysts will be in advantage when using YARA rules to leverage the analysis.

Finally, another noteworthy use case is endpoint scanning. That’s right, YARA scanning at the client computer. Since YARA scanning engine is multi-platform, it poses no problems to use Linux developed signatures on a Windows operating system. The only problem one needs to tackle is on how to distribute the scan engine, pull the rules and push the positive matches to a central location. Hipara, a host intrusion prevention system developed in C, is able to perform YARA file based scans and report results back to a central server (7). Another solution would be to develop an executable python script featuring the YARA module along with REST libraries for pull/push operations. The process have been documented, including conceptual code,  in the SANS paper “Intelligence-Driven Incident Response with YARA” (read it here). This use case stands as the closing of the circle in IOC development, since it enters the realm of live IR, delivering and important advantage in the identification of advanced threats.

Conclusion

The key point lies in the ability for the IR teams to introduce the procedures for YARA rule creation and use. Tier 1 analysts should be instructed on how to use YARA to enhance incident triage, provide rule feedback, concerning false positives, and fine tuning to Tier 2 analyst. Additionally a repository should be created in order to centralize the rules and ensure the use of up-to-date rules. Last but not least teams should also agree on the rule naming scheme, preferably reflecting the taxonomy used for IR. These are some of the key steps for integrating YARA in the IR process, and to prepare teams for the IOC sharing process.

References:

  1. https://github.com/plusvic/yara
  2. https://plusvic.github.io/yara
  3. https://blog.didierstevens.com/2014/12/17/introducing-oledump-py
  4. https://github.com/buffer/thug
  5. https://github.com/volatilityfoundation/volatility
  6. https://github.com/kevthehermit/YaraPcap
  7. https://github.com/jbc22/hipara
Tagged , , ,

Neutrino Exploit Kit

[First of all Happy New Year to all the readers!
In this summary I would like to briefly describe one component that is part of many parts which form the Internet malware industrial complex. The Exploit Kits (EK’s) which impact users and corporations of all sizes on a daily basis. The
 article below was possible due to the insights and knowledge received from @Kafeine. ~LR]

The EK’s are powerful and modular weapons that deliver malware in an automated fashion to the endpoint by taking advantage of client side vulnerabilities.

Exploit Kits are not new and have been around at least for the past 10 years or so. Nonetheless, they have evolved and are now more sophisticated than ever. The malware authors behind them enforce sophisticated capabilities that evade detection, thwart analysis and deliver reliable exploits. Basically, by introducing malicious code in a web server an attacker can turn a legitimate web server into a mechanism to deliver malicious code by taking advantaged of client-side vulnerabilities against unpatched browsers and applications. This attack vector is known as watering hole or strategic web compromise when it targets a trustworthy web site. In recent years the Exploit Kits have evolved and became very sophisticated weapons and profitable business for the ones involved. The malware authors continue to develop sophisticated capabilities to prevent detection, analysis and deploy exploits for new vulnerabilities in a very reliable manner.

In the last days I had the chance to look at one recent campaign of drive by download that leverages the Neutrino Exploit Kit to infect systems with CryptoWall. The diagram below illustrates the different components of the Neutrino Exploit Kit and how they work together.

neutrinoframework

 

  • User browses to the compromised web server.
  • Web server contacts the backend infrastructure in order perform various check and to generate malicious java script code. These checks include things like verification of victim IP address and its Geo-location. Furthermore within the malicious JavaScript code there are new domain names and URLs that are generated dynamically by the backend.
  • The browser processes and decodes the malicious JS. In the observed infection the malicious JavaScript checks the browser version and if it matches the desired version, it stores a cookie and processes a HTML iframe tag.
  • The iframe tag triggers the browser to perform a request to another URL which is the Neutrino Exploit Kit landing page.
  • The landing page is hosted in a randomly generated host using DGA which needs to be resolved via DNS. The authoritative domain to answer these domains are owned by the threat actor. The answers received by the DNS server have a time to live (TTL) of a few seconds. The domains are registered on freely available country code top level domains (ccTLD).
  • The victim then lands in the exploit kit landing page which by its turn delivers a small HTML page with an object tag defined in its body. This object tag directs the browser to load Adobe Flash Player and then use it to play the SWF file specified in the URL. In case the victim does not have Adobe Flash player installed, the browser is instructed to download it.
  • The browser as instructed by the object tag, downloads the malicious Flash file.
  • The obfuscated and encrypted SWF file is played by the Flash Player and exploits are triggered based on available vulnerabilities. The Flash file contains exploits for CVE-2013-2551, CVE-2014-6332, CVE-2015-2419 affecting Internet Explorer and CVE-2014-0569, CVE-2015-7645 affecting Adobe Flash.
  • If the exploitation is successful, shellcode is executed and the malware is downloaded and launched. In this case we observed that the malware delivered has been CryptoWall.

The threat actors behind Neutrino are finding vulnerable websites in order to host their malicious JS  content globally in a repeatable and automated fashion. Furthermore, In the last few days Neutrino has been abusing the registration of free domains registered inside the country code top level domains (ccTLD) such as  .top, .pw, .xyz, .ml, .space and others. The different landing pages have been pointing to a server hosted in Germany and in another cases in Netherlands. In another blog post I will go into more details about it.

 

References:
https://www.trustwave.com/Resources/SpiderLabs-Blog/Neutrino-Exploit-Kit-%E2%80%93-One-Flash-File-to-Rule-Them-All/
http://research.zscaler.com/2015/08/neutrino-campaign-leveraging-wordpress.html
http://www.cert.gov.uk/wp-content/uploads/2015/12/Demystifying-the-exploit kit.pdf
http://www.malware-traffic-analysis.net/2015/09/17/index.html
http://malwageddon.blogspot.ch/2015/03/data-obfuscation-now-you-see-me-now-you.html
http://malware.dontneedcoffee.com/2014/11/neutrino-come-back.html

Tagged , , , , , ,