10 - OllyDbg hints

Before moving forward into actually reversing something, its a good idea to quickly step through some basic debugging terminology, which you will hear all the time. We'll use OllyDBG as a reference; download both OllyDBG 1.10 and OllyDBG 2.0. There are some features that are available only in the older version. I'll mention the older version whenever needed; otherwise just assume I'm talking about the newer Olly.

1. You can either 'Open' a new executable or 'Attach' to a running executable.

2. Midway through a debugging session, you will want to return to the start many times to understand things better. Use Ctrl+F2 to restart the session.

3. After opening an executable in Olly you will want to run it. Use F9 to run it

4. To analyze the executable you will almost certainly want to break execution midway so you can study it part by part. Move cursor to highlight that line and hit F2 to set a breakpoint. Once you set a breakpoint and then hit F9, your program will run till the breakpoint and wait for user input. If you hit F9 again it will start running again.

5.Programs have functions that are called from within the main program. These functions might be user defined functions or actual system calls. At any time you might want to see how the program is behaving, at ay point in any function. If you want to explore the behavior of a specific function, you must "Step Into" the function using the F7 key. If you know what the function is doing and are interested only in what happens AFTER the function is called, you must use the F8 key to "Step Over" the function.

6. Once you've got to a certain point in the program and want to see where you came from; you can use the '-' key to move the cursor backward and the '+' key to move it forward. This won't actually "re-run" the program; it'll help you understand where you jumped from or the exact path through the code that your program has chosen.

7. If the program that you are debugging is a command line program and needs arguments to even start; you can use the File - Set new arguments menu option to supply those

8. If you want to search for Strings you can right click in the main window and go to "Search for" - All referenced strings

9. To go to a particular memory address you can right click and select Go to -> Expression and type the exact memory address you want to visit

10. You can right click on most values and choose to "Follow in Dump" (bottom left) to understand their content

11. You can hit Ctrl+N to find out all the functions useed by the program and Ctrl+M to find specific sections in memory

12. You can Pause a program by hitting F12

There are plenty of other options as well and they're all explorable yourself or by reading documentation for Olly which is available online. However if you are fully clear about at least all of these options, you should be good to go. We'll explore a few other options as we go along reversing various types of executables along the way.

Next time we will look at a malicious executable and dynamically as well as statically analyze the same. Until then..have fun :)

Read More

9 - Static Malware Analysis

We briefly looked at static analysis in Parts 3,4 & 5 and that's what you should read first if you want an introduction. However, that was with Linux as the base OS and the programs that we chose were just to give us a feel about how high level code (mainly control structures) would look in a debugger. In this series we're trying to study malware; which primarily affects Windows systems (for whatever reason ;)) and understand all its functionality - even those bits which aren't necessarily exposed when we initially run it. So for e.g there might be some malware which performs keylogging in the background; but wouldn't necessarily have a button called "Start Keylogger after 5 minutes".. so dynamic analysis might might miss it. But proper static analysis won't.. it'll take longer to identify stuff - of course but you will eventually find it.

Now we're almost always only going to have a single executable to analyze. We will almost certainly NOT have any source code available. If you did, the process of reverse engineering would be much simpler; you would only have to study the syntax for that particular language carefully and you would reach a conclusion about what that malware did, much much quicker. Since we have only the EXE and no code - we'll have to try and reconstruct code in some way and then draww our conclusions.

That's where a disassembler comes in. There's plenty of stuff available about disassemblers online; you can read up on them in detail if you're interested. However for the purpose of this article; its enough to mention that a DA just takes the EXE; opens it; and converts it into assembly language so its easier for you to read. After all its easier for you to understand an assembly language instruction rather than a lot of alphanumeric data joined together :). Have a look at an example: What would you say if you saw something like "EB 27" and told that it had some meaning? What would you then say if you were told there were 1,00,000 such lines and you needed to find out the meaning of each of those and find out what the malware did at the end of all of it? Not too much fun if you ask me. What a disassembler does is simply convert "EB 27" into an assembly instruction which will say "JMP 27 bits forward" from where you currently are. It'll do it for all 1,00,000 lines. So you need to look at assembly instructions instead of plain alphanumeric gibberish. Clearer? But yes, its still 1,00,000 lines. If you think its no big deal, just wait till you start reversing :)

So once an EXE is loaded into a disassembler and the assembly code is completely generated its time to start trying to understand it. "Understand" in malware analysis means - 'Its time to DEBUG it'. Remember gdb in Linux? For Windows we're going to use a tool called OllyDBG which will DA and DBG the EXE. Using a debugger you can control exactly how much the malware runs. You could for e.g say 'Run only the first 10 lines of assembly code. I'll study what changes were made and then you can continue.' We're doing this, to understand exactly how the program works. Makes sense? Excellent :)

So to sum up, if we want to improve at static reverse engineering, we need to understand assembly language (at least enough so we can read code), learn how DA's and DBG's work and understand how to use our tools in the best possible way. As we move on it will become necessary to understand more and more about Windows functions, and when and why they are called. MSDN will quickly become your friend :). This is what I will recommend you read; in the order that I've mentioned:

a) Malware ForensicsInvestigating and Analyzing Malicious Code
This is very basic and focuses primarily on Dynamic Analysis. So if you're clear about Dynamic Analysis and understand systems reasonably well at a high level you can skip this. If not, spend some time browsing through this.

b) Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code
This is an excellent book but is a little too advanced and wont help you immediately. Reading it after around 6 months or so in detail will help. However its a good idea to read Chapters 1,6 and 7 from this book. Again the focus is on dynamic analysis at this point; but spend a day or 2 on just these chapters.

c) Reversing: Secrets of Reverse Engineering
This book by Eilad Eldam is probably a must read for anyone starting off in Static reversing. Yes there are plenty of tutorials and plenty of videos and plenty of more advanced books available..but for me this was the book which helped me through those initial days when I was struggling to learn. It gives you just about enough.. just the right amount that you need to know about reversing before you move forward. Again, there are places you will get stuck even in this book but as long as you understand about 50% of it and learn how to use Olly better by the time you're through - you're good to go. Don't read beyond Chapter 6 when you're starting out.. that's all you need. Chapter 6 was for me; the most helpful chapter.. I could work my way through it very slowly and gain confidence.

d) The IDA PRO book
Eventually at some point of time in your reversing learnings, you will start using IDA PRO. There's a book completely dedicated to the same. It is 'rumoredly' the best disassembler in the market and if you get better at it you will want to use IDA at some stage. That said, its better to understand GDB, Olly and other slightly simpler tools..get your basics clear and then understand IDA. Don't START your career with IDA.

e) Windows Internals - 5th edition
The book contains everything about Windows. The better you are at understanding Windows internals the better you will get at analyzing malware. However, this is NOT a newbie book. I struggled for over 2 weeks reading its content, reading a course by F-Secure based on this book, reading various presentations and PDFs which had this as a reference...but it was just far far too complex for me. I was very frustrated at my lack of progress :(. That's not to say the book is bad, of course it is not but for someone who is starting out... I would not recommend it. Maybe a year or 2 later, when you're much clearer about the basics.. it will be a good reference.

Well... that is it for an introduction to Static reversing. I recommend you do a little bit of reading [from any of these books or even better sources] before proceeding forward. Its not compulsory but a few basics are always helpful :)

In the next article I will try and explain the key features of OllyDBG - just the ones that you need to know before you start out. There is documentation available of course, but a gentle introduction to "just what you need" will help you for sure.

Happy reading :)

Read More

8 - Dynamic Malware Analysis Procedures

Hello again. Today I discuss the procedures that I follow while analyzing both categories of Malware as mentioned at the end of the previous article. Here is the procedure for Malware that you can analyze even if it does not talk to servers on the Internet.

NON-INTERNET MALWARE

1. Assign Static IPs to both machines; it'll help later ;)
2. Start the Ubuntu controller(192.168.56.101) and then start the clean victim XP machine(192.168.56.102)
3. Start inetsim on controller
4. Start tcpdump on controller and configure it to write the packet capture to an output file
5. Copy the malware to the victim machine
6. Start Autoruns on the victim machine and Save state [.arn format]
7. Take 1st shot and save with Regshot [.hiv format]
8. Start Wireshark on victim machine [Set Capture and Display filters as per your convenience]
9. Start ProcessExplorer. Pause ProcessExplorer state [Hit SpaceBar to Pause]
10. Start ProcessMonitor [Its very verbose; be prepared to get comfortable with how to filter traffic]
11. Start Capturebat on victim machine [Create a batch file which calls Capturebat with all needed arguments]
12. Start Malware and wait for around 1 minute [Its up to you really, but 1 minute is enough in most cases]
13. Stop ProcessMonitor [Because its the most verbose; just stop capturing data]
14. Stop Wireshark on victim
15. Stop CaptureBat on victim
16. Restart ProcessExplorer to get newer processes [Hit space bar again]
17. Get strings for disk and memory snapshot of relevant process from Process Explorer and save the same [2 separate files]
18. Rerun Autoruns and compare with earlier output to find out discrepancies [compare with previous .arn]
19. Take 2nd shot with Regshot and save. Compare with previous shot to find discrepancies [compare with previous regshot file]
20. Save all events captured by Process Monitor [.pmon is fine; Process Monitor gives you plenty of filtering options]
21. Save CaptureBAT logs on victim
22. Save prefetch files on victim [C:\Windows\Prefetch]
23. Save cookies on victim [If the malware has created any]
24. Save deletedfiles directory from CaptureBAT logs if it exists [Its a folder called "logs" inside the CaptureBat program files directory]
25. Identify modified or added files from Capture BAT and Regshot logs and save all those files [After studying the logs]
26. Save pcap file in Wireshark running on victim
27. Stop tcpdump on Controller and save pcap file
28. Stop inetsim and save the generated report [inetsim gives you a path for the saved report; copy that over]
29. Zip all the victim logs and sftp over to the controller
30. Copy all victim and controller logs and save them on the host
31. Delete all data specific to that malware from the controller
32. Reset the victim image to a clean snapshot and repeat the process for the next malware sample you study

INTERNET MALWARE

The processes to be followed wrt the victim are exactly the same. The controller however is not needed here and we will allow Internet bound traffic from the victim. VirtualBox will be set up in NAT mode for this purpose. The following guidelines must be kept in mind while allowing the malware to communicate with the Internet.

1. No private data should be present on the victim image that malware could potentially steal
2. TOR is configured on the host and the victim image hence communicates with the outside world through TOR [This is needed because malware sites might block you if they see too much traffic from the same IP address; like in your case]
3. Start Wireshark on the Host
4. All other Internet activity on Host is stopped to allow a cleaner pcap file for analysis purposes. Capture filters can be set in Wireshark if one knows how the malware is going to communicate
5. Ensure that Internet connectivity is present between the Victim image and the Host
6. In case malware does not work properly or it appears no traffic is being captured on the Host despite everything seemingly okay; check what ports the malware is trying to talk on. You can get this from the Pcap file on the victim machine. Once you get this adjust the firewall on your Host to temporarily allow the relevant traffic
7. Run the malware after starting all victim relevant executables discussed in the previous section
8. Once the malware finishes running, store all victim relevant data directly on the HOST and not the controller
9. Stop Wireshark on the Host and save it in the relevant location
10. Reset the victim image to a clean snapshot and repeat the process for the next malware sample you study

NOTE: There is a risk involved here in allowing malware to talk outside; but there are times when it is impossible to study its true behavior without allowing it to talk to servers on the Internet. It'll help in such cases to do a little static analysis and understand what the malware is trying to do; before allowing traffic through. I know though, that we haven't yet talked about static analysis - we'll do that soon.

NOTE: I haven't explained how exactly to configure each tool. I've given small tips in brackets for some of them; but the vast majority of tools are very simple to use so I'll just leave them to you to figure out. Do ping back if you get stuck though; I'll try and help :)

Read More

7 - Tools:dynamic analysis

Now that you have a working Malware Lab setup, the next step is for you to install a few tools which will enable you to monitor the behavior of malware that you run inside the WinXP unpatched machine. You effectively need to monitor does on the local machine [Files, registry, memory] and what it does on the network..i.e How does it try and communicate with the outside world?

This blog post will just illustrate the tools that I personally think are a good starting point. It is not by any means a list which includes every available tool. I will cover what needs to be on the victim system and what needs to be on the host and how to use these tools. The procedure can obviously be tweaked to include or remove anything you feel is not needed. Here we go :)

WinXP [Victim machine] - Autoruns, Regshot, Wireshark, Process Explorer, Process Monitor, CaptureBAT, Psftp
Ubuntu [Malware controller] - Tcpdump, Burp, Inetsim, Ssh[server]

Autoruns - Programs that run automatically on startup
Regshot - Tells you exactly what files and registry keys have changed
Wireshark - Saves network traffic to a file
Process Explorer - Details of what processes were started and stopped
Process Monitor - Details of each and every operation [very low level] done by every process
CaptureBat - Similar to ProcessMonitor but more high level. Also saves files that the malware deletes from the hard disk
Psftp - Sftp client to transfer all results to controller for archiving purposes

Tcpdump - Wireshark equivalent on Linux
Burp - HTTP/HTTPS proxy [You will need it if the malware communicates with other machines using these protocols]
Inetsim - Simulates a lot of services like Ftp, Dns, HTTP, IRC and many others. You may be able to analyze malware without allowing it to go out on to the Internet.
SSHd - SSH server to allow victim machine to connect to; to transfer data.

Yes, that is all you need to perform dynamic or behavioral analysis of malware. Its of course a work in progress. As and when there is a better tool available or something that needs to be added we can add the same at a later date. Now I divided the analysis into 2 parts - Malware which does not need to communicate with the Internet and malware which will not work unless it "calls home". I wrote 2 small procedures for handling both these cases; which I will share with you in the next article. Do get your lab setup and take a snapshot of your VM once all the tools are properly installed. Doing this is very important; as you'll have to reinstall all your tools again..each time you analyze a single piece of malware. That is not fun.. trust me :)

Until next time...goodbye.

Read More

6 - Malware Lab Setup

I'd started off learning Reversing last year and touched on the basics of reversing in a Unix environment; we also analyzed a few basic C programs in gdb to understand patterns in Assembly language and how common patterns of code looked inside a debugger. If you've read all of those tutorials you would understand a little of what I was trying to communicate. If you need a little more brushing up of your Assembly syntax, I strongly advise you spend a day or so looking at Vivek Ramachandran's fantastic Assembly language videos on securitytube.net. There are 11 parts to it; very lucidly explained - do take your time and study all of them.

I've been spending a lot of time trying to understand how malware works over the last 2 months or so. I have stuck to Windows this time because a large majority of malware runs only on Windows systems. I started off learning Dynamic Malware Analysis and have over the last month or so dived into Static Analysis. I hope to explain all my learnings to you in this series of blogs over the next few days. Lets start :)

In my first post on Reverse Engineering last year I briefly touched on the types of Analysis. There is a great presentation by Lenny Zeltser there; if you've seen it you will know that its extremely important to set up a lab if you're serious about Malware Analysis. This "lab" can be as small as 2 physical machines or 1 physical machine with a VM running on it. Since a vast majority of the people reading this will be people with a single laptop or desktop in their possession, I will stick to a simple setup with a single physical machine and multiple Virtual Machines (as needed) on it, so you can hit the ground running :)

My lab configuration is as follows:

Ubuntu 10.04 Host [500G HDD, 4GB RAM, Intel i3 processor]
Virtual Machine 1 -WinXP with Malware tools [Not updated]
Virtual Machine 2 - Ubunutu 10.04 Malware controller [Not updated]

Effectively as long as you have a reasonably powerful host machine which can run multiple VMs at the same time, you should be okay.

The WinXP machine is the one on which I will load and run all my malware samples to understand their behavior. The controller is the machine that all the analysis data is transferred to, after the malware has run. You don't need the controller VM at times; you can just store reports on the host. I just chose to keep it as a VM because the entire setup is more easily transferrable if so needed, at a later date to another machine.

Once this high level setup was decided; these were the guidelines I followed while setting up the host as well as the VMs.

1)Latest version of VirtualBox downloaded and installed
2)Configure the firewall [iptables] on your host to drop incoming packets from the Malware infected machines
--- Drop all from victim
--- Accept all INPUT stateful connections [This is for the OUTPUT chain]
--- Allow Outbound SSH to Malware controller
--- Allow HTTP,HTTPS and outbound DNS access
--- Drop everything else on all chains
3)Use a host-only networking configuration. [NOTE: Vboxnet0 is used for communication between the host and the VM; not eth0]
4)Disable shared folders between the host and target or make them read-only
5)Prevent the target from accessing any shared devices or removable media, such as USB drives that may be physically connected to your host
6)Do not customize your target system with any sensitive information
7)Default route added on victim machine to route all traffic to the controller; sniffing working
8)Configure Iptables on the controller.
--- Allow inbound SSH from Host
--- Allow all INPUT traffic from Malware Client 1
--- Allow all stateful OUTPUT traffic
--- Drop all other traffic across all chains

At the end of this you should effectively have a Host machine with 2 Vms set up and all 3 talking between each other as expected. A tip I will give is to leave the Firewall configurations for the very end, after you are sure the machines can talk properly to each other.

The aim in the end is to ensure that traffic from your malware machine doesn't leak out on to the Internet unless you know exactly what you're doing. Do whatever you need to do to secure it as much as you can. In the next blog we will take a look at what tools need to be installed at minimum; on the various machines.

Read More

COMING SOON- NEW USER INTERFACE

NEW USER INTERFACE UPDATE , soon in AppStore

Read More

Interface Changes-Updates

15 May 2011: THE MOBILE DOCTOR Interface change

Dear All

We made some changes to MD Software and especially in the interface screens for greater efficiency.

See the changes by click here

Examples of new screens

Read More