Malware Analysis Ruxcon 2005

1. Malware AnalysisRuxcon 2005 Nicolas Brulez Virus Researcher

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 a disassembler, 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, and rebuild the import table.

5. First Steps: Is my file Packed? • 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. First Steps: Is my file Packed?

7. First Steps: Unpacking • Unpacking knowledge is very handy for Reverse Engineers. • Most malwares are packed to hide their real code from Disassemblers. • There are a lot of different PE packers and PE protectors out there, and many have no public unpackers. • Fortunately, most packers (and “Protectors” :P) are easy to remove.

8. First Steps: Unpacking • Find the Original Entry Point • Trace slowly until you jump to the real program code. • Use Static Disassembly to find the jump to original entry point. • Smart use of hardware breakpoints. (Write access is your friend). • Breakpoints on API Functions. • Use Stack (pushad is your friend) • Dump the process to disk • Using tools such as LordPE or Imprec Process dumpers.

9. First Steps : Unpacking • Reconstruct the Import Table • Trace the packer’s code and find where the IAT handling is, so you can grab information about the import table and reconstruct it manually, eventually. (or patch the protector so it will not destroy the imports at all ) • You can just use “Import Reconstructor” to reconstruct the import table and get ride of the boring work most of the time. • Sometimes we need to write plugins for Imprec, but usually it only takes a dozen minutes.

10. Disassembly • Once our file has been unpacked, we can start disassembling it, looking for malicious code.

11. Unpacking Demo

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 main functions of the malware.

13. Finding interesting code in Malwares • Imports You can use imports to find interesting parts of a malcode. Eg: • Registry Functions to find whether it is adding binaries to XP firewall’s whitelist, or if it’s going to start when Windows is loading etc. • Socket Functions to find whether it is binding a port on local machine, trying to connect on remote websites, sending informations on remote machines etc. • File Functions to find whether it drops files, or copy itself to the windows directory, etc • Process Functions to find whether it starts a process, or looks for running processes (AV, firewalls...) and terminate them etc.

14. Finding interesting code in Malwares • 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 to kill them • Sending infected emails to infect people • Binding a shell on a port for remote access • etc...

15. Finding interesting code in Malwares • 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 the file 100%, if we have 98% of the imports rebuilt, it’s all we need to do static analysis.(yes, we can be lazy too  ) • They thought that making their console application, a « GUI » application, would trick someone.. Unfortunately, it did not work. 

17. Example: A Proxy Trojan Protocol R.E • I saw many interesting strings inside the binary:

18. Example: A Proxy Trojan Protocol R.E • The malcode author is so nice with us

19. Example: A Proxy Trojan Protocol R.E • 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 Console application.

20. Example: A Proxy Trojan Protocol R.E • Looks good, doesn’t it? • Now we can reverse the protocol and see nice information in the console window. Helps finding out what’s wrong with our parameters.

21. Example: A Proxy Trojan Protocol R.E • Let’s try to Reverse Engineer the remote command feature. • Does it match « CTL  »?

22. Example: A Proxy Trojan Protocol R.E • 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 socket buffer. (The recv functions is a good hint).

23. Example: A Proxy Trojan Protocol R.E • We learn that we need to send « CTL findme something » here.

24. Example: A Proxy Trojan Protocol R.E • Third parameter is used as an index to select the command to execute.

25. Example: A Proxy Trojan Protocol R.E • 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. Example: A Proxy Trojan Protocol R.E • 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 very small. He most likely use some sort of logging, to know which computers are infected. • This one was easy, but most of the malwares are THAT easy.

27. Questions? • If you have any questions, please talk SLOOOWLY, or just come to talk to me after the presentation. (Better :p) • Thanks  nbrulez@websense.com http://WebsenseSecurityLabs.com