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
• ol)
• 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
• rganisation 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
• ols 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

• bfuscated (see

http://www.signal11.eu/en/research/articles/m

• n 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
• 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

• ol:

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

• ol:

Four candidates

• Searching on Remote Access T
• ol 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

• ur sample

RAT: Remote Access T

• ol

Nuclear RAT

• Traffic characteristics does not match
• ur case; data is sent in clear

Remote Administration T

• ol

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

• ol

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

• ol

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

The vulnerability: Process stalking (2)

• No vulnerability can be spoted right away in

the code

• Throwing random data at the client doesn’t

work either

• We need to look deeper

The vulnerability: Fuzzing PI by instrumenting the server

• Idea: when the data is encrypted, we need to fuzz it

before the encryption takes place

• Then we need to implement that encryption in the

fuzzer code … could be time consuming

• Not really ! We can use PaiMei and instrument the PI

server; modify its function parameter while it is running, if we know what to modify

• I knew the encryption functions, I figured it out

during the analysis !

• It is what the PI fuzzer does; runs the server many

times while changing bytes just before the encryption function is called

The vulnerability: Poison Ivy fuzzer code

The vulnerability: We’ve found a candidate !

• This way, our fuzzer was able to

produce a positive result:

The vulnerability: What has happened ?

• We have overwritten a fixed length

buffer of 0x8001 bytes on the stack

• The overwrite was possible because

Poison Ivy client does not check for the length value (it correctly verifies the encrypted data length thought)

• The length value is sent as a 32bit

DWORD and the payload follows; we could overwrite a lot on the stack …

• The overwritten buffer is located one

step up in the function call chain

The exploit

• Can we transform this into working exploit ?
• First try failed; I tried to use the famous SEH

technique but that is pretty well protected even under Windows XP SP2; cannot dispatch the execution to an arbitrary address

• I then focused on the classic function RET pointer
• verwrite but there are some problems to solve:

– How do we locate the code on the stack ? – We need to traverse two RET s as the function

• wning the buffer is one step up in the call chain –

can we make it ? – Will the program be still working or will it crash after the payload has started or finished ? – Do we need to reverse or copy all the encryption and program logic to our exploit code ?

The exploit: How do we locate code in the stack ?

• We are lucky – seems that Borland Delphi compiler

doesn’t care about the stack unwinding when the function is the one that started the thread

• The EBP register is preserved and points to where our

code is located

• it is enough to find the CALL EBP instruction somewhere

– this is just two bytes: \xFF\xD5, great chance to find !

The exploit: Are we able to traverse the two RET s ?

• Yes we are. We need to do two things:

– We need to drive the execution flow the shortest path possible as the stack will be smashed – We need to provide some fake pointers to writable regions

• f memory, so the program doesn’t crash on access

violations

• The first thing can be achieved by deliberately sending

less data than declared in the length field that we

• verflow; the program will assume the error

condition and go straight towards the first RET, and then the second RET

• The second thing will be met by feeding the program

with addressable memory pointers on the stack where it accesses the variables

The exploit: Will the exploit be stealthy ?

• Poison Ivy client works internally by

assigning one thread to each connection; it is a multithreaded server

• It should be easy then to just exit the

thread we are running, if we don’t damage any data

• In Metasploit Framework, we can do it by

setting the EXITFUNC variable to « thread »

The exploit: Do we need to reverse a lot ?

• Not nececarilly; we can use PaiMei to

instrument the PI server, just like we used it during the fuzzing process

• This way, we drive the execution of the PI

server, stop it in the appropiate place and modify the length value and the buffer (needs to be shorter than declared!)

• Then we just continue the execution to make

the server encrypt everything for us, and send it towards the PI client !

The exploit: The layout of the overflown buffer

The exploit: DEMO

The intelligence from the field: How cyberspies operate

• Impressive number of victims with

different group IDs

The intelligence from the field: The network infrastructure

• T

wo-tier infrastructure; the IP where the server connects to is never a real C&C, it is always a proxy server

• The proxy server often located in a

different country

The intelligence from the field: Stealing documents

• Browsing directory structure, looking

for documents

The intelligence from the field: Listening to keystrokes

• Looking at the keylogger data

The intelligence from the field: Looking at mailboxes

• Uploading mail browsing tools

The intelligence from the field: Cracking passwords

• Looking at stolen password hashes

The intelligence from the field: Spreading further

• Creating new PI server

The intelligence from the field: The operating procedures

• Defined operation hours (around 12h) – starting

around 3-4h in the morning, terminating 15-16h

• Weekend is weekend – no work
• Using VMware virtual machine, reverted to the base

snapshot at the beginning of each day of work

• USB key is used as the working directory for Poison

Ivy; it is used at the end of the day to transfer newly stolen documents to somewhere else

• The USB key contains massive amounts of stolen

documents sorted by organisation, keylogger data, password hashes, and hacking tools

QUESTIONS ?