Malware Analysis Nicolas Brulez

8/6/2019 Malware Analysis Nicolas Brulez

http://slidepdf.com/reader/full/malware-analysis-nicolas-brulez 1/27

Nicolas Brulez

Virus Researcher

Nicolas Brulez

Virus Researcher

http://www.go2pdf.com/



2

Agenda

§ Introduction

§ First Steps

– File Format Analysis : Is my file packed?

– Unpacking

– Disassembly

§ Unpacking Demo

§ Finding interesting code in Malwares (Basic but works most of the time)

– WinMain

– Imports

– Threads

– Strings

§ R.E Example: – Malware Protocol Reverse Engineering




3

Introduction

§ Reverse Engineering Malcode is most of the time a fairly

easy task (Easier than porting Linux to a closed device)

– We don’t need to patch the Binary (most of the time)

– We don’t need to understand everything

– We can skip big sections of code – We can make big assumptions

– We don’t need to fix the unpacked files most of the time,except if we want to debug it




4

First Steps: Is my file Packed?

§ What is Packing anyway ?

– Allows to compress/encrypt applications

– You can’t see the code of the application using adisassembler, you need to unpack it first.

– Packers compress applications and add a small loader

to the file. – The loader will uncompress the binary in memory,

resolve imports, and call the Original Entry Point (OEP).

– We need to find OEP and dump the process to disk, andrebuild the import table.




5


§ Is the last section executable ?

§ Is the first section writeable ?

§ Is the first section's raw size null ?

§ Is the Entry Point starting in the last section ?

§ Check the section names

§ Check the Import Table : Very few imported functions ?

§ Check the strings : no strings at all ?

§ Is the Raw Size way smaller than the Virtual Size?Compressed!




6





7

First Steps: Unpacking

• Unpacking knowledge is very handy for Reverse Engineers.

• Most malwares are packed to hide their real code fromDisassemblers.

• There are a lot of different PE packers and PE protectors outthere, and many have no public unpackers.

• Fortunately, most packers (and “Protectors” :P) are easy toremove.




8

First Steps: Unpacking

§ F ind the Original E ntry Point

– Trace slowly until you jump to thereal program code.

– Use Static Disassembly to find thejump to original entry point.

– Smart use of hardware breakpoints. (Write accessisyourfriend).

–

Breakpoints on API Functions.– Use Stack (pushad isyour friend)

§ Dump the process to disk

– Using tools such as LordPE or I mprec Process dumpers.




9

First Steps : Unpacking

§ Reconstruct the Import Table

– Trace the packer’s code and find where the IAT handlingis, so you can grab information about the import tableand reconstruct it manually, eventually. (or patch theprotector so it will not destroy the imports at all J)

– You can just use “Import Reconstructor” to reconstruct

the import table and get ride of the boring work most ofthe time.

– Sometimes we need to write plugins for Imprec, butusually it only takes a dozen minutes.




10

Disassembly

§ Once our file has been unpacked, we can start

disassembling it, looking for malicious code.




12

Finding interesting code in Malwares

§ WinMain

For malware written in C/C++, you will quite often find interesting

information right at the WinMain function.

WinMain is NOT the first thing being executed in a binary, unlike

most people think. There are a few things done by the compiler first.IDA usually will identify the WinMain function for us, but it is

fairly easy to do it manually, by looking at functions parameters near

the entry point. (and API functions call, eg: GetModuleHandleA).

Sometimes, malcode will just make a Mutex and create various

threads at WinMain. It is therefore very easy to find the mainfunctions of the malware.




13


§ Imports

You can use imports to find interesting parts of

a malcode. Eg:

• Registry Functions to find whether it is adding binaries toXP firewall’s whitelist, or if it’s going to start whenWindows is loading etc.

• Socket Functions to find whether it is binding a port onlocal machine, trying to connect on remote websites,sending informations on remote machines etc.

• File Functions to find whether it drops files, or copy itselfto the windows directory, etc

• Process Functions to find whether it starts a process, or

looks for running processes (AV, firewalls...) and terminatethem etc.




14


§ Threads

A lot of malwares are using threads to run their different payloads:

– Scanning hard drives for WAB Files

– Scanning memory for Firewalls and Anti Virus programs tokill them

– Sending infected emails to infect people

– Binding a shell on a port for remote access

– etc...




15


§ Strings

Strings are also a quick way to find interesting code, as many

malcode authors are just too lazy (or naive, because they

think the fairly new packer they found is going to save them)

to encrypt them.

Once unpacked, you can often use strings to find protocols

keywords, website used to download new malwares, or upload

stolen information (keylogging) etc.




16

Example: A Proxy Trojan Protocol R.E

§ Don’t forget that most Malcode authors are naives (or

stupids).

§ This one was packed with an old version of Asprotect(Commercial PE Protector), yet we don’t need to rebuild thefile 100%, if we have 98% of the imports rebuilt, it’s all weneed to do static analysis.(yes, we can be lazy too J )

§ They thought that making their console application, a« GUI » application, would trick someone.. Unfortunately, itdid not work. J




17


§ I saw many interesting strings inside the binary:




18


§ The malcode author is so nice with us




19


§ When we run this malcode we will never see those strings

on our screen.§ I assumed they were lazy or naives, and made their

application a GUI one, so we actually don’t see anything.

§ Fire up your favorite PE Editor and make it a Consoleapplication.




20


§ Looks good, doesn’t it?

§ Now we can reverse the protocol and see nice informationin the console window. Helps finding out what’s wrong withour parameters.




21


§ Let’s try to Reverse Engineer the remote command feature.

§ Does it match « CTL »?




22


§ The code is looking for « CTL » inside a buffer, and if we

scroll up a little bit, we will find that, it’s actually, a socketbuffer. (The recv functions is a good hint).




24


§ Third parameter is used as an index to select the command

to execute.




25


§ Switch Jump Table

– CTL 1 findme : This will Clean Registry and ExitProcess

– CTL 2 findme 31337 : This will change the server Port.

– CTL 3 findme 94 : This will change the collector Port.

– Etc ...




26


§ All the other commands work the same way, so we can

reverse engineer the whole proxy protocol.§ We could easily « flood » the collector with bogus

information by chaning the interval to something verysmall. He most likely use some sort of logging, to knowwhich computers are infected.

§ This one was easy, but most of the malwares are THATeasy.




27

Questions?

§ If you have any questions, please talk SLOOOWLY, or just

come to talk to me after the presentation. (Better :p)

§ Thanks J

[email protected]

http://WebsenseSecurityLabs.com

http://websensesecuritylabs.com/

http://websensesecuritylabs.com/


Malware Analysis Nicolas Brulez

Documents

Transcript of Malware Analysis Nicolas Brulez