Hello and welcome to my Introduction thread on Malware Analysis.
In this thread I will be discussing a bit about which software you may wish to have set-up in your analysis environment and at the end of this thread I will briefly explain a bit about the analysis environment.
[Disclaimer]:
This will be the first thread (Introduction) to a set of threads I will be making regarding Malware Analysis, and hopefully by the end of it you may have learnt something to help you with analysis of malicious software. I will try to make my threads as easy-to-read as possible for beginners but also whilst maintaining interest of people who may have some background experience in malware analysis and are not so beginner.
No samples will be provided in this thread, nor will any analysis actually occur. This thread strictly evolves around helping you become a bit more equipped with some useful tools for malware analysis, and will provide a brief section of information regarding virtualised environments/protecting yourself whilst performing analysis.
When I release more malware analysis threads the links will be provided at the end of this thread for easy-access to them.
[End of disclaimer]
When you are performing analysis on malware (“malicious software”) there will be two different types of analysis. The first type of analysis you can perform is known as static and the second type of analysis you can perform is known as dynamic. I will explain more thoroughly about static/dynamic analysis however to put it in short: static analysis is analysis of the sample whilst it is not running whereas dynamic analysis is analysis whilst the sample is running.
When you perform static analysis you will not have the sample running in memory (it won’t be running at all - you will be analysing the sample on disk and any other files associated/packed with it). In the scenario of static analysis, you have the ability to attempt to perform techniques such as (but not limited to): disassembly, checking imports/exports (for example, imported functions and which libraries they are from), strings (scan through to collect all the identified “strings” in the program and check if you can make out for them meaning anything important/useful), check the code signing on the sample (if it has any and check if it’s valid if it does), checking for usage of packing/obfuscation, performing a scan with online AV engine detection services to see if the sample has been identified by another vendor already (a good service for this would be VirusTotal and there are software based tools to let you scan the file with VT via the API – this can be useful because if you find that another vendor detects the sample already as a threat, you can be sure to keep a closer eye out and potentially dig deeper into finding something malicious embedded within the sample (by that I am referring to either something packaged with it or the same itself being involved in execution of malicious code, I am sure I was understood correctly though)).
When you perform dynamic analysis the sample will be running in memory (in other words the sample will be running). In the scenario of dynamic analysis, you have the ability to attempt to perform techniques such as (but not limited to): debugging, dumping the sample to disk (helpful if it was packed), monitoring the APIs it calls, monitoring network traffic, monitoring registry/file access (also linked to API call monitoring but thought to note it separately here) and more. Overall we can do a lot to discover how the sample is working if the static analysis attempts either do not go well or do not find out much for us – an example of when static analysis won’t work alone is when the developer of the malware has tried hard and put a lot of work into protecting his sample and therefore we cannot obtain much information without bypassing this protection, which we can do as long as we know what he has done. If he uses a packer to pack his sample, then we can perform dynamic analysis to debug the sample and at the right time try methods like dumping the sample from memory to disk (and then perform static analysis on that dumped sample).
If you have a lot of samples to get through in a short period of time, then you may not bother going further after finding evidence of malicious activity (and you may then mark it as malware by the threat type based on the evidence you found) since it is not practical to go through finding every single detail you can about a sample. However, should you find yourself performing further analysis (or for educational/curiosity purposes after gaining interest in a specific sample for whatever reason) you may wish to dig deeper for more details within the sample to learn exactly how it works, eventually hitting the bottom line with nothing else to find.
There are times when static analysis will be used more than dynamic analysis and vice versa. You will most likely find yourself mixing static and dynamic analysis techniques quite often to get a better understanding of how the sample actually works.
Recommended tools
Static analysis:
IDA Pro (disassembly – there is a free version available for beginners but the Pro version is recommended).
PE Explorer (dissecting and analysing binary files – dependency scanner, digital signature viewing, inspecting the Portable Executable Sections/Header and more relating to analysis of the binary file itself – there is a free and paid version).
PEiD (relating to packing identification).
LordPE (relating to dumping programs from memory, re-building the PE if it becomes broken and has other uses).
Dynamic analysis:
OllyDbg (debugging - although IDA Pro also has support for debugging).
Wireshark (sniffing the network to monitor network activity by the malware sample).
RegShot (registry monitoring – allows you to create a snapshot log of the registry before and after running the sample and then compares the changes).
Process Monitor (API monitoring – for example, allows us to see modifications to registry in real-time by filtering out registry functions to be monitored).
Process Hacker/Process Explorer (real-time process execution monitoring).
Some more tools you may be interested in using (or may prefer as alternate to other tools listed above): WinDbg, FileAlyzer, ImpRec, Resource Hacker, Scylla, Universal Import Fixer, API Monitor, Detect It Easy.
Before I end the topic of tools for the malware analysis environment for this thread, you may be interested in the Malcode Analysts Pack. It contains a series of tools to help you with malware analysis.
Malware Analysis environment information
It is very important that you have a proper testing environment for malware analysis. You should not run live malware on your system unless it is a dedicated system for malware analysis (and even then the system should be correctly set-up and you should have some precautions, such as backups for reversing the effects and quickly cleaning the system). It’s highly recommended and practical for you to have a Virtual Machine for your malware analysis since it is not always an option for someone to get a completely separate system for malware analysis (and using a virtual machine can be much simpler and quicker). If you are performing analysis on a spare system then you can work with roll-back software, although I recommend against doing this for now at least.
For the Virtual Machine I recommend you either use VMWare (workstation) or VirtualBox. I personally think that VMWare is more secure than VirtualBox although it is paid unlike VirtualBox.
A common feature included with VM software (included in VMWare and VirtualBox at least) would be the ability to take snapshots of the current session and revert back to them in the future. The way it works is when you take the snapshot it saves a copy of that session, meaning when you revert back to that snapshot, all changes which occurred after the snapshot was taken become reverted like they never occurred in the first place. This is extremely useful when performing malware analysis since you can take a snapshot after you have set-up your analysis environment (with all your tools for example) and then after performing analysis on a sample and saving all the information about it you need, you can revert back to the snapshot which will clean the infection off the OS and leave you with the state you were in from before you ran the malware. Then you can continue to analyse another sample, and it goes on and on in a loop.
When using Virtual Machine software and executing malware from within the Virtual Machine on the Guest OS (the OS you have installed and are running in the Virtual Machine), you need to be aware that you are not necessarily indefinitely secure and that it is technically possible for the Virtual Machine software to be exploited which can lead to your host OS becoming compromised by the malware. Nothing is completely bulletproof however there are some things you can do to reduce any chances of having your host OS compromised, such as disabling features such as Shared Folders/Clipboard access (to and from the host to the guest OS) which the malware may attempt to exploit (whilst performing analysis – you can use them when you aren’t performing analysis). Without that being said, there are many things within VM software an attacker could attempt to exploit, although it is extremely rare for malware to compromise the host OS and when such vulnerabilities are found and then exploited, the developers of the VM software patch these vulnerabilities through future updates as fast as possible. Therefore, make sure you are running the latest version of the VM software before performing malware analysis, you never know what zero-day fresh malware will do or where it really originates from before analysing, and better be safe than sorry!
On your host OS it would be wise to have a firewall installed. Most firewalls can actually intervene with connections which are on-going from within the Virtual Machine guest OS. If your firewall picks up a malicious connection coming from the malicious sample you are executing from within the VM, it can block it (or more preferably show an alert to let you decide). This can be handy because you may not want yourself being associated with connecting and downloading from malicious hosts (or uploading to them), remember to keep your IP address protected in the case of malware connecting to the internet for whatever reason.
As well as this, it is wise to have a VPN (Virtual Private Network) setup on your host OS. The reason for this is because if the malicious software from within the VM opens connections to its own hosts (e.g. maybe for downloading additional malware or just sending information it acquired from the virtual environment, or for another reason), it would be leaking your real IP address if you haven’t got a VPN setup. Whereas if you had set-up a VPN prior to starting up the VM and then analysing the malware, your real IP address won’t be leaked by the malware at all if you have network ability setup from within the VM settings.
The people making/distributing the malware to infect people are bad enough. If they obtain your IP address, then they may attempt to perform attacks such as DDoS (Distributed Denial of Service) which will use up your network resources (and thus eventually using up all your bandwidth to prevent you from using your internet for anything else until the attack stops).
For VPN (Virtual Private Network) I recommend CyberGhost (there is both a free and paid version).
If you are having trouble with analysing a sample, you can try to submit it and check the results with an online malware analysis service. If you are not aware of such services, they essentially allow you to upload a Portable Executable to their server and then it will perform the execution and analysis on their side (usually both static and dynamic analysis). Once the analysis has been completed the results are returned back and allow you to overview information such as: dropped files, registry modifications, Anti-VM check attempts, API calls in general, etc.
Some examples of good online malware analysis services (which are either specifically for or support PE files):
Malwr - Malware Analysis by Cuckoo Sandbox
Free Automated Malware Analysis Service - powered by VxStream Sandbox
Deepviz - Analyze
Thank you for reading and hopefully this thread helped you.
Wave.
In this thread I will be discussing a bit about which software you may wish to have set-up in your analysis environment and at the end of this thread I will briefly explain a bit about the analysis environment.
[Disclaimer]:
This will be the first thread (Introduction) to a set of threads I will be making regarding Malware Analysis, and hopefully by the end of it you may have learnt something to help you with analysis of malicious software. I will try to make my threads as easy-to-read as possible for beginners but also whilst maintaining interest of people who may have some background experience in malware analysis and are not so beginner.
No samples will be provided in this thread, nor will any analysis actually occur. This thread strictly evolves around helping you become a bit more equipped with some useful tools for malware analysis, and will provide a brief section of information regarding virtualised environments/protecting yourself whilst performing analysis.
When I release more malware analysis threads the links will be provided at the end of this thread for easy-access to them.
[End of disclaimer]
When you are performing analysis on malware (“malicious software”) there will be two different types of analysis. The first type of analysis you can perform is known as static and the second type of analysis you can perform is known as dynamic. I will explain more thoroughly about static/dynamic analysis however to put it in short: static analysis is analysis of the sample whilst it is not running whereas dynamic analysis is analysis whilst the sample is running.
When you perform static analysis you will not have the sample running in memory (it won’t be running at all - you will be analysing the sample on disk and any other files associated/packed with it). In the scenario of static analysis, you have the ability to attempt to perform techniques such as (but not limited to): disassembly, checking imports/exports (for example, imported functions and which libraries they are from), strings (scan through to collect all the identified “strings” in the program and check if you can make out for them meaning anything important/useful), check the code signing on the sample (if it has any and check if it’s valid if it does), checking for usage of packing/obfuscation, performing a scan with online AV engine detection services to see if the sample has been identified by another vendor already (a good service for this would be VirusTotal and there are software based tools to let you scan the file with VT via the API – this can be useful because if you find that another vendor detects the sample already as a threat, you can be sure to keep a closer eye out and potentially dig deeper into finding something malicious embedded within the sample (by that I am referring to either something packaged with it or the same itself being involved in execution of malicious code, I am sure I was understood correctly though)).
When you perform dynamic analysis the sample will be running in memory (in other words the sample will be running). In the scenario of dynamic analysis, you have the ability to attempt to perform techniques such as (but not limited to): debugging, dumping the sample to disk (helpful if it was packed), monitoring the APIs it calls, monitoring network traffic, monitoring registry/file access (also linked to API call monitoring but thought to note it separately here) and more. Overall we can do a lot to discover how the sample is working if the static analysis attempts either do not go well or do not find out much for us – an example of when static analysis won’t work alone is when the developer of the malware has tried hard and put a lot of work into protecting his sample and therefore we cannot obtain much information without bypassing this protection, which we can do as long as we know what he has done. If he uses a packer to pack his sample, then we can perform dynamic analysis to debug the sample and at the right time try methods like dumping the sample from memory to disk (and then perform static analysis on that dumped sample).
If you have a lot of samples to get through in a short period of time, then you may not bother going further after finding evidence of malicious activity (and you may then mark it as malware by the threat type based on the evidence you found) since it is not practical to go through finding every single detail you can about a sample. However, should you find yourself performing further analysis (or for educational/curiosity purposes after gaining interest in a specific sample for whatever reason) you may wish to dig deeper for more details within the sample to learn exactly how it works, eventually hitting the bottom line with nothing else to find.
There are times when static analysis will be used more than dynamic analysis and vice versa. You will most likely find yourself mixing static and dynamic analysis techniques quite often to get a better understanding of how the sample actually works.
Recommended tools
Static analysis:
IDA Pro (disassembly – there is a free version available for beginners but the Pro version is recommended).
PE Explorer (dissecting and analysing binary files – dependency scanner, digital signature viewing, inspecting the Portable Executable Sections/Header and more relating to analysis of the binary file itself – there is a free and paid version).
PEiD (relating to packing identification).
LordPE (relating to dumping programs from memory, re-building the PE if it becomes broken and has other uses).
Dynamic analysis:
OllyDbg (debugging - although IDA Pro also has support for debugging).
Wireshark (sniffing the network to monitor network activity by the malware sample).
RegShot (registry monitoring – allows you to create a snapshot log of the registry before and after running the sample and then compares the changes).
Process Monitor (API monitoring – for example, allows us to see modifications to registry in real-time by filtering out registry functions to be monitored).
Process Hacker/Process Explorer (real-time process execution monitoring).
Some more tools you may be interested in using (or may prefer as alternate to other tools listed above): WinDbg, FileAlyzer, ImpRec, Resource Hacker, Scylla, Universal Import Fixer, API Monitor, Detect It Easy.
Before I end the topic of tools for the malware analysis environment for this thread, you may be interested in the Malcode Analysts Pack. It contains a series of tools to help you with malware analysis.
Malware Analysis environment information
It is very important that you have a proper testing environment for malware analysis. You should not run live malware on your system unless it is a dedicated system for malware analysis (and even then the system should be correctly set-up and you should have some precautions, such as backups for reversing the effects and quickly cleaning the system). It’s highly recommended and practical for you to have a Virtual Machine for your malware analysis since it is not always an option for someone to get a completely separate system for malware analysis (and using a virtual machine can be much simpler and quicker). If you are performing analysis on a spare system then you can work with roll-back software, although I recommend against doing this for now at least.
For the Virtual Machine I recommend you either use VMWare (workstation) or VirtualBox. I personally think that VMWare is more secure than VirtualBox although it is paid unlike VirtualBox.
A common feature included with VM software (included in VMWare and VirtualBox at least) would be the ability to take snapshots of the current session and revert back to them in the future. The way it works is when you take the snapshot it saves a copy of that session, meaning when you revert back to that snapshot, all changes which occurred after the snapshot was taken become reverted like they never occurred in the first place. This is extremely useful when performing malware analysis since you can take a snapshot after you have set-up your analysis environment (with all your tools for example) and then after performing analysis on a sample and saving all the information about it you need, you can revert back to the snapshot which will clean the infection off the OS and leave you with the state you were in from before you ran the malware. Then you can continue to analyse another sample, and it goes on and on in a loop.
When using Virtual Machine software and executing malware from within the Virtual Machine on the Guest OS (the OS you have installed and are running in the Virtual Machine), you need to be aware that you are not necessarily indefinitely secure and that it is technically possible for the Virtual Machine software to be exploited which can lead to your host OS becoming compromised by the malware. Nothing is completely bulletproof however there are some things you can do to reduce any chances of having your host OS compromised, such as disabling features such as Shared Folders/Clipboard access (to and from the host to the guest OS) which the malware may attempt to exploit (whilst performing analysis – you can use them when you aren’t performing analysis). Without that being said, there are many things within VM software an attacker could attempt to exploit, although it is extremely rare for malware to compromise the host OS and when such vulnerabilities are found and then exploited, the developers of the VM software patch these vulnerabilities through future updates as fast as possible. Therefore, make sure you are running the latest version of the VM software before performing malware analysis, you never know what zero-day fresh malware will do or where it really originates from before analysing, and better be safe than sorry!
In the case of malware exploiting the Virtual Machine and executing code on the host OS, you could use a spare system and have a VM running within that (this is discussed further below). One big purpose of using another system for analysis (dedicated malware analysis system) is down to malware checking for presence of virtualisation, although if you are debugging via dynamic analysis you can try to bypass these checks and fool it into thinking it’s not being executed within a virtual environment – there should be a dedicated thread to anti-vm malware in the future.
On your host OS it would be wise to have a firewall installed. Most firewalls can actually intervene with connections which are on-going from within the Virtual Machine guest OS. If your firewall picks up a malicious connection coming from the malicious sample you are executing from within the VM, it can block it (or more preferably show an alert to let you decide). This can be handy because you may not want yourself being associated with connecting and downloading from malicious hosts (or uploading to them), remember to keep your IP address protected in the case of malware connecting to the internet for whatever reason.
As well as this, it is wise to have a VPN (Virtual Private Network) setup on your host OS. The reason for this is because if the malicious software from within the VM opens connections to its own hosts (e.g. maybe for downloading additional malware or just sending information it acquired from the virtual environment, or for another reason), it would be leaking your real IP address if you haven’t got a VPN setup. Whereas if you had set-up a VPN prior to starting up the VM and then analysing the malware, your real IP address won’t be leaked by the malware at all if you have network ability setup from within the VM settings.
The people making/distributing the malware to infect people are bad enough. If they obtain your IP address, then they may attempt to perform attacks such as DDoS (Distributed Denial of Service) which will use up your network resources (and thus eventually using up all your bandwidth to prevent you from using your internet for anything else until the attack stops).
For VPN (Virtual Private Network) I recommend CyberGhost (there is both a free and paid version).
If you are having trouble with analysing a sample, you can try to submit it and check the results with an online malware analysis service. If you are not aware of such services, they essentially allow you to upload a Portable Executable to their server and then it will perform the execution and analysis on their side (usually both static and dynamic analysis). Once the analysis has been completed the results are returned back and allow you to overview information such as: dropped files, registry modifications, Anti-VM check attempts, API calls in general, etc.
Some examples of good online malware analysis services (which are either specifically for or support PE files):
Malwr - Malware Analysis by Cuckoo Sandbox
Free Automated Malware Analysis Service - powered by VxStream Sandbox
Deepviz - Analyze
Thank you for reading and hopefully this thread helped you.
Wave.
