T argeted attacks: from being a victim to counter attacking - PowerPoint PPT Presentation

T argeted attacks: from being a victim to counter attacking Andrzej Dereszowski deresz <at> signal11.eu www.signal11.eu

Motivation • Are we able to counteratack ? • Different possibilities: • Traditional network scan and attack known open ports • Running honeypot with infected documents to steal • Discovering new vulnerability in the backdoor program intruders use

Outline • Intro • Scenario • Analysis of an infected document • RAT (Remote Administration T ool) • Closer look at Poison Ivy RAT • Unobfuscating the code • The vulnerability • The exploit (demo) • The intellingence from the field

Intro: targeted attacks • Highly focused on particular organisations (or organisation type) • Making less noize than the « non-targeted » malware • The most popular attack vector is an e-mail with an infected document or link to a web page with an exploit • T ools used to maintain the control and infiltrate the target are more individual-oriented (designed for managing less machines, but you can do more with a single machine) • Main focus on stealing documents (amongst other things ...)

Intro: targeted attacks (2) • Different attackers from different countries with different skills • Simplest attacks: only social engineering « here is your unpaid bill: http://badness.com/bad.exe » • More advanced attacks: infected DOC/PPT/PDF or link to a web page • The most advanced: 0-day vulnerability exploited in MS/Adobe products

Scenario • Our scenario starts here: an e-mail with the PDF attached was sent to a pharmaceutical company • The PDF, when opened, makes the Adobe Reader disappear for a second, and then reappers with an « analysis of the future of the drug market » • Closer analysis and Internet search reveals that the article was copied from the news • The analysis of the PDF file reveals that it exploits a vulnerability in Collab.collectEmailInfo in Adobe Reader up to 8.1.1 (CVE-2007-5659)

Scenario (2) • Althought this was not 0-day at this time, the system was not patched (quite common with Adobe products until recently) • The security products (the AntiVirus and the IDS system) failed to block the threat becasue the JavaScript in the PDF was obfuscated (see http://www.signal11.eu/en/research/articles/m on how easy is to fool the AV)

Static analysis: Malicious JavaScript • Static analysis: the PDFTK (PDF toolkit) or the pdf-parser.py • After uncompressing, the following code is visible:

Static analysis: shellcode analysis Malicious JavaScript contains shellcode: We discontinue the static analysis because it's too time consuming – let's move on to dynamic analysis

Dynamic analysis: Network footprint Network footprint: 256 bytes sent right after a successful TCP handshake. These bytes appear random; they are different with each run:

Dynamic analysis: Behavioral analysis • This is to give the overall picture what's going on in the system: Process Monitor can be used, or some publicly available sandboxing services: Sunbelt CWSandbox, ThreatExpert, Anubis • Using these tools it is easy to see that the code injects remote threads to other processes and creates new processes as well • T o get to the final code we need to follow all these hops • This will serve as a base for the third element of dynamic analysis: code debugging

Dynamic analysis: Debugging code • First, the code calls CreateRemoteThread() in the explorer.exe process • We can attach a second copy of the debugger to explorer.exe and break exactly where the new remote thread starts

Dynamic analysis: Debugging code (2) • The hopping is not over; the injected explorer.exe thread calls CreateProcess() on iexplore.exe in the suspended state,injects code and resumes the process • We can use the good old method; find the injeced code in the injecting process, and modify its frist bytes to jump-to-itself. The thread in iexplore.exe process will wait for us in the infinite loop

Dynamic analysis: Debugging code (3) This seems to be a right payload: • Position independent code: CALL ESI + n, where ESI is a base register

Dynamic analysis: code walk-through

Remote Administration T ool: Introducing the term RAT • Now we now something about the code, let’s check if it’s not something that we can grab from the Internet • According to Wikipedia: A Remote Administration Tool (known more commonly on the Internet as a RAT ) is used to remotely connect and manage a single or multiple computers with a variety of tools, such as: • Screen/camera capture or control • File management (download/upload/execute/etc.) • Shell control (usually piped from command prompt) • Computer control (power off/on/log off) • Registry management (query/add/delete/modify) • Other product-specific function • Watch out for terminology: server is the remote part, client is the GUI C&C part

Remote Administration T ool: Four candidates • Searching on Remote Access T ool gives some results. After analysis, I chosed four that seem most popular and can be publicly downloaded: – Nuclear RAT – Gh0st RAT – Bifrost Remote Controller – Poison Ivy • Let’s analyse each of them to check if some of them match to what we already know about our sample

RAT: Remote Access T ool Nuclear RAT • Traffic characteristics does not match our case; data is sent in clear

Remote Administration T ool Gh0st RAT • Infamous one, played main role in the GhostNet report • The network footprint of this one does not match either because, even if it’s encrypted, it starts the transmission with the string « Gh0st », which is not our case

Remote Administration T ool Bifrost Remote Controller • This one seems close to what we are observing, at first glance • Data is encrypted, but it is 9 bytes more than 256 • If looked at closely, we can see that the first four bytes desribe the length of the encrypted part • Not our case either

Remote Administration T ool Poison Ivy RAT • The traffic characteristic is a 100% match; 256 random bytes • The code from the generated server matches as well • That means: WE’VE FOUND THE RIGHT ONE !

Closer look at Poison Ivy: Introduction • Free for download at its home site: www.poisonivy-rat.com • The license says you can order special, undetected version • It also says that updating to new version is very easy because the remote part does not need to be updated

Closer look at Poison Ivy: The architecture • In the Poison Ivy naming convention (other RAT s as well), the client is the GUI console and the server is the remote agent siting in the infected computer

Closer look at Poison Ivy: The server • Generated from within the client with user supplied options (IP to connect, password etc.) • Very small: around 6 kb of code (position independent), all the rest sent on-demand from the client • Hides very well in the system: I’ve seen behavioral tools failing to detect it because they couldn’t reconginze the API calls • Generate options include: – Password when authenticating with the client – IP address to connect to – Is starting at boot or no – Where to drop the EXE – Whether to perform the code injection, etc, etc.

Closer look at Poision Ivy: The client

Closer look at Poison Ivy: The client Its capabilities include: File manager • File shredder • Registry manipulator • Process viewer and manipulator • Services and driver viewer • TCP/IP relay proxy • Active connection and port lister • Remote cmd.exe shell • Password dumper • Key logger • Screen and audio capture • Inernet camera capture • Has plugin architecture that allows writing more •

Closer look at Poison Ivy: The comms • Site says it uses Camelia Encryption • Challenge-response authentication: first 256 random bytes is a chalenge, the client sends the response and the server verifies if the client knows the password • The encryption is not well implemented; re- seeding the crypto with each trasmission

Closer look at Poison Ivy: The comms (2) • The encryption routines can be spotted by seeing a lot of arithmetic operations • By tracing how these function work, we can locate the password – very important

Unobfuscating the code • Distributed obfuscated by ExeStealth v2.7x, as identified by DiE.exe (Detect-It-Easy), PEiD failed to detect it • The code is written in Borland Delphi • The packer performs antidebugging tricks such as spaghetti jumps, jumping to the middle of instruction, checking « BeingDebugged » flags, calculating the CRC over its own code • There is an easy trick to unpack this: after the first Access Violation exception, place the breakpoint on the CODE section – the next break will be OEP • We need to hide the debugger; PhantOm for Olly is ok! • The final step is to use Import Reconstructor with the appropiate plugin to rebuild the exe

Unobfuscating the code (2)

The vulnerability: Process stalking • After making sure the program works after rebuilding it, we are ready to have closer look at it • It contains loads of code, so we probably have to figure out which part we are interested in • Let’s employ Process Stalking technique and use the PaiMei by Pedram Amini – an excellent debugging framework writen in Python