I've finally managed to analyze a piece of malware dynamically as well as statically and thought I'd share my experience about the same. I downloaded this malware from this site. This site and many others contain plenty of live malware you can download for educational purposes. I did a dynamic analysis of the malware by following the procedure I listed out in a previous blog post and drew a few conclusions. Those were:
--- The malware in question was a 6 part malware
--- 3 of those at least seemed to be 'spam' malware, which registered on sites and posted links to porn sites
--- 1 seemed to install TOR
--- The last bit of malware seemed to delete system files and crash the OS itself [Thanks to snapshots; this isn't as painful as it could be ;)]
So what I'll do in this first sample though, is take just 1 part of this 6 part malware and analyze it[static and dynamic].. independently. The name of this malware was aolsbm.1.exe. Its MD5 is 5a2be07ad750bed86be65954fb9d7d21. You can search for this on the site previously mentioned or on Offensive Computing if you want to try it out yourself. I do strongly recommend you do this, otherwise there really is little point reading further as it is a 'Hands On reversing' series after all :). That immediately meant that it was mostly a Windows executable. I copied the executable into my WinXP VM and set up all my tools as per the procedure I listed out earlier. I tried analyzing it without having a valid Internet connection; but quickly found out that this malware needed one as it was trying to create an account on some site online. So I restored an old snapshot, copied the malware onto it again, connected the VM to the Internet and then re-ran the malware.
Note that whenever you let malware do something online, you must be in a position to stop what it is doing, if it is something dangerous. In this case the worst thing it could do is post spam on a website. While this is not something good...it is not too dangerous and we can let it run at least once to see how things work. The other thing is that prior to letting the malware connect to the Internet, I had run the malware multiple times in a 'non internet' environment and studied as much as I could about it. Only if things absolutely do not work..and you cant understand what the malware is doing...should you allow Internet connectivity. So in a nutshell...I first follow the 'Without Internet' part of my procedure and only then go to the 'With Internet' part. Lets move on.
Now after running the malware you would have numerous logs available to you from the numerous tools. Please refer to a previous blog post to understand the purpose of each tool. The first and simplest thing I did was compare the Autorun state of the machine, before and after the malware was run. This can be done using the 'Compare' feature of Autoruns. The first line there said it all with a new registry entry added for aolsbm.1.exe. This means the malware will run each time the machine is restarted.
I then looked at ProcessExplorer to see if aolsbm.1.exe was still running. It was running and was purple in color. This meant that the executable was packed by default and unpacked in memory. A packed executable usually reveals much less information than an unpacked one with respect to hard coded strings or the API's that it uses internally. So its a good idea to try and unpack it if you can. ProcessExplorer though has a feature where you can look at hard coded strings for the process of the exe on disk as well as memory. The strings on disk hardly gave anything away about the process apart from a few APIs that it used..right at the end. This fits into our theory of packed executables not revealing anything.
Looking at the unpacked version though in memory gives us a wholly different picture. A few key things that I found were -
--- Microsoft Visual C++ Runtime Library
--- Visits by a browser to aol.com and other related sites
--- Numerous form fields like Username,Password,Birthyear,Birthmonth etc...giving us a feel that there is some registration that is happening.
--- Something about lifestream..which on googling is found to be AOL's social networking platform
--- Numerous strings related to logging in and logging out of some site
--- Embedded IE being used [Not clear what this is..but lets look at this later]
--- A lot of long randomly spelt domain names ending in .com
--- Numerous API's that are used in the program [GetProcessHeap, TlsFree, CreateFileA] and many many more. All these are clues about what may be going on inside. For e.g Tlsfree could mean there is something related to SSL inside this executable..maybe it makes an SSL connection somewhere.
There is plenty more that can be deciphered by carefully reading what all is found but we'll go on..as you understand the purpose of strings on disk and memory. As a little exercise do compare the outputs of process strings on disk and memory. It'll be very clear as to why packed executables are so difficult to analyze :)
Lets now see if the malware left any other traces of itself on disk. We already know it made 1 registry entry to ensure it started on each reboot. Lets look at the logs from Capturebat to see what else...if anything..it did. Now the log is big at 348K so we will want to first try and look at only what the process aolsbm.1.exe did. We can then look at the complete log for any further information. You can use find or grep to get only the lines that contain aolsbm.1.exe. Here's 1 way you can do it - grep.exe aolsbm.1.exe c:\malware_outputs\aolsbm\capture.txt > c:\malware_outputs\aolsbm\capture_aolsbm.txt
We can reduce the lines we need to look at even further by looking only at unique lines. Here is how this can be done - cat c:\malware_outputs\aolsbm\capture_aolsbm.txt | uniq -u > c:\malware_outputs\aolsbm\unique_capture_aolsbm.txt
Look at the size of the file unique_capture_aolsbm.txt now. Its just 32K :) [Strangely though, this isnt completely unique, there still seem to be duplicate lines, but it'll do for now]. Of course there will be times when you need to look at the whole file, but to start off this is good enough. I'll mention a few interesting observations from this file now:
--- 2 files that are written to: c:\Windows\lgo and C:\soft20110729_AOL.log. Interesting..the 2nd file at least; it seems to be like a log by the name of today's date. Maybe a log of all the things the process did?
--- Plenty of writes into the Temporary Internet Files folder. This clearly means a browser was used (mostly IE) and it accessed the Internet and wrote a lot of things into this folder. That means the Internet was definitely accessed.
--- It created many cookies as well for the aol.com domain. Look into the cookies folder on your system.
--- The Autorun registry key right at the top [This confirms it]
Lets quickly look at the output for Regshot now. Regshot also gives us the exact values that were set for each change made..thus bloating the file up. It is however a good double check tool. Scroll right down to the FilesAdded section and beyond...it will more or less confirm what we've already said so far was changed on the system.
Lets finally look at what Wireshark says about Network traffic. We've been saying it talks to the Internet..rt? Here's a few interesting things I found:
--- The file size is 392K which means there is something going on :)
--- There's a request made to google.com; this is probably just to check if Internet is working. It can't be anything else IMO coz google.com is not a malicious site
--- Once that comes back there are requests made to funny sounding domains for the file .sys.php. One of these domains sends a 404 back but one sends a 200 Ok back. Further traffic is then sent to this site.
--- After a few packets there is traffic destined to aol.com and various other sites, including lifestream [remember?]
--- An SSL connection is made and a lot of data exchange is done. Probably even a login is done over this connection, we cannot see this obviously as its all encrypted. Remember we saw Tls API's in the memory strings? This confirms that as well.
--- If you run the malware multiple times you will see many domains being contacted...which means that the selection of the domains.. the logic to do that is also present somewhere in the executable.
Well.. that was a lot of stuff. We didn't use all the tools to their fullest capacity but that's okay. ProcessMonitor for example is extremely verbose and can give us even more info at a much lower level, but we don't need it just now. Remember, the purpose of dynamic analysis is to gain an understanding of what the malware is doing..at a high level. It is primarily through static analysis via a debugger that you will understand how exactly it does the things that it does. And static analysis is more complex :)
That does it for dynamic analysis. Do set up a virtualized environment yourself and play around with this piece of malware which can be found here. Do be careful though and don't violate any rules ;). I've also analyzed this same executable in OllyDbg [static analysis] and that is what we will look at the next time. While performing static analysis you'll find that its extremely useful to know what the exe does..before diving into the code heads on.
Bye for now :)
Showing posts with label dynamic. Show all posts
Showing posts with label dynamic. Show all posts
Friday, July 29, 2011
Sunday, July 17, 2011
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 :)
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 :)
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.
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.
Saturday, July 16, 2011
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.
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.
Subscribe to:
Posts (Atom)