February | 2016 | Count Upon Security

Feb 29 2016

Retefe Banking Trojan

Back 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.

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.

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.

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.

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!

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.

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.

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.

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 here, here 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.

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.

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.

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.

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 Banking Malware, Operation Emmental, Retefe Banking Trojan, Retefe;

Feb 18 2016

2 Comments

Digital Forensics and Incident Response, Malware Analysis

Unleashing YARA – Part 2

In 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:

YARA 3.4.0 (get it here)
pescanner.py (get it here)

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:

a suspicious string that seems to be related with debug information
the MD5 hash of the .text section
the .rsrc section with high entropy
the symbol GetTickCount import
the rich signature XOR key
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:

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:

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:

pescanner.py initial report

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:

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

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

Tagged Malware Analysis, pescanner.py, REMnux, YARA

Feb 15 2016

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.

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].

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.

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).

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 Angler Exploit Kit, Locky Ransomware, Neutrino Exploit Kit, TeslaCrypt

Feb 10 2016

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_logo I 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:

Tagged Incident Response, Malware Analysis, Threat Intelligence, YARA

Count Upon Security

Increase security awareness. Promote, reinforce and learn security skills.

Monthly Archives: February 2016