Mutt
Professional
- Messages
- 1,167
- Reaction score
- 835
- Points
- 113
The first steps
So, let's imagine for a start that we have an infected machine on our hands. The first step is to perform three main steps: isolate the computer from others on the network, take a memory dump, and take a disk image.
When disconnecting an infected computer from the network, it is worth remembering that if we are dealing with an encryption virus, then there is a chance of losing user data. Malware can start encrypting them when the connection to the network is interrupted, so the first thing to do is assess how important the data on the infected PC is and whether it is worth the risk.
It would be best to create a virtual network (VLAN) for quarantine with Internet access and move the infected PCs there. In a large company, this will require the coordinated actions of cybersecurity employees and network administrators, in a small company, the versatile skills of a single sysadmin.
Next, you need to take a memory dump. This is done from the very beginning, because when copying the hard disk, you will need to turn off the computer and the contents of the RAM will be lost. It is best to run the program that takes the dump from an external media, so as not to leave unnecessary traces on the hard disk - we will need the data from it unchanged.
To prevent malware from reacting to system shutdown, the easiest way is to pull out the power cable. The method, of course, is barbaric, but it guarantees an instant shutdown. Keeping data on the hard drive intact is more important to us than worrying about the health of other components.
Next, we start the PC using bootable media with any operating system in forensic mode and software to get an image of the hard disk. The most commonly used disk image is E01 (Encase Image File Format). It is supported by a large number of applications for both Windows and Linux.
INFO
Forensic mode is booting without mounting physical disks. This allows you to exclude the introduction of any changes to the investigated disk. Forensic professionals also use devices to block any attempts to access the disc for recording.
Examining dumps
Memory and disk dumps most likely contain everything we need - the body of the malicious program and the traces left by it. We can start searching.
I recommend starting by examining the copy of the disk, and using the memory dump if you cannot find any traces on the disk, or as an additional source. When analyzing the contents of the disk, first of all, we pay attention to the startup, the task scheduler and the initial boot sector of the disk.
The Microsoft website has documentation on autoloading services and libraries.
To understand how the malware got into the computer, it is worth examining the time of creation and modification of files on the disk, browser history, and user's mail archive. If you manage to establish at least an approximate time of infection, then this will be a plus. There are quite good collections of paths in the file system and registry on the Internet that you should pay attention to first.
You can also extract some unique information from the memory dump, for example, what documents and browser tabs were opened at the time of infection, what were the active network connections, work processes (including hidden ones).
File analysis
When you have a suspicious file in your hands, you will need to somehow make sure that this is an instance of a malicious program. Of course, if it is a known virus, then it can be detected by an antivirus (there is a website virustotal.com for checking all antivirus engines at once). But more and more often we come across unique cases that are not detected by antivirus programs. Such malicious programs have the FUD (Fully UnDetectable) status.
Also, it cannot be ruled out that you are faced with a zero-day threat - one that no one knows about yet (and the developers have zero days to eliminate it - hence the name). Malvar, which exploits zirodei and has the FUD status, poses a serious threat not only to individual computers, but also to entire companies.
Before starting the analysis of a suspicious file, you must do the following.
INFO
Under no circumstances connect the stand to the corporate network - this can cause massive infection of other computers.
There are two approaches to software analysis - dynamic and static. As a rule, for the best effect, a method that is more suitable for the situation is used, or both methods at the same time. For example, it may be necessary to examine the behavior of a malicious program to identify characteristic markers without analyzing algorithms. Therefore, the choice of methods and tools may change during the analysis.
Static analysis
Let's start with static analysis, as it does not require you to run malicious code and will definitely not cause an infection on your computer.
Let's take a look at the initial headers of a Windows executable.
1. DOS header file, also known as DOS stub. Thanks to it, it is possible to run a program in DOS (usually the message This program cannot be run in DOS mode is displayed). You can see the beginning of the title by the characteristic letters MZ
Executable file header
2. Immediately after the first is the header used by modern OSes with all the necessary parameters for the executable file (for example, offset to the import / export table, the beginning of the executable code section). The beginning of the title can be found by the characteristic letters PE, and a description of the format is available on the Microsoft website .
We can say that the header of the executable file contains a guide about where and what exactly is inside the file itself, what permissions should be granted to sections, all settings for correct operation, so analysis of the header can provide valuable initial information.
In addition, you need to see if there are any string data in the files. From them, you can subsequently identify such files or even get important information like the addresses of management servers.
Malware developers are always faced with the task of masking their creation as much as possible and complicating detection and analysis in every possible way. Therefore, packers for executable files are very often used.
INFO
Packers are utilities for compressing and encrypting executable files. They are used not only by malware creators, but also by developers of legitimate software to protect their programs from being hacked. Self-written packers, specially designed to complicate analysis, are not always detected by programs and require additional actions from the analyst to remove the packaging.
A deeper (and at the same time, complex) analysis of any executable files is the use of disassemblers. Assembler code is more understandable for humans than machine code, but because of the volume, it can be far from easy to understand. In some cases, it is possible to restore the source code of programs in a high-level language by decompilation - if it is possible to determine which compiler and obfuscation algorithm were used.
Glossary of terms
Assembler code
Pseudocode
Dynamic analysis
Reading pseudo-code or assembly language is like untangling a ball of thread - painstaking and time-consuming. Therefore, you can use another type of analysis - dynamic. Dynamic analysis involves launching an executable file and tracking its actions, such as accessing registry branches, sending and receiving data over the network, and working with files.
WARNING
Dynamic analysis involves launching the file under investigation. This must be done on a virtual machine that is isolated from other computers to avoid the possibility of malware spreading over the network.
You can analyze the behavior of a program by monitoring and intercepting the launch of applications at the OS level, or by connecting to a running process and intercepting calls to libraries and APIs. And in order to analyze in detail the process of program execution, it is best to use one of the debuggers.
INFO
Debugger is a utility or set of utilities that is used to test and debug the target application. The debugger can simulate the work of the processor, and not run the program on real hardware. This gives a higher level of control over execution and allows you to stop the program under specified conditions. Most debuggers are also capable of stepping through the execution of the code under study.
It doesn't matter if you use a debugger or some program that allows you to control API calls, you have to work in manual mode. This means that in-depth knowledge of the operating system is required, but you will receive the most complete data about the object of study.
However, the analysis can also be automated. For this, the so-called sandboxes are used - test environments for running software.
Sandboxes are divided into two types: offline and online. To get the most complete picture, I recommend using multiple data sources at once and not excluding any of the sandbox types. The more information you collect, the better.
Analysis example
Since malware analysis always depends on practical skills, this article would be incomplete without demonstrating it with an example. We will carry out an express analysis and establish the nature of the executable file.
First, let's define the sequence of actions. Here's what we need to do:
To store the file, I recommend that the first thing to do is to change the extension, for example to Sample._exe, in order to avoid accidental startup. We take a snapshot of the virtual machine on which we will run the executable file (the initial state of the system to us still come in handy), and calculate the hash sum of the file.
Getting the hash sum of a file
Let's copy the result and use virustotal.com for verification.
Checking the hash sum on virustotal.com
As you can see from the screenshot above, the VT verdict is 54 out of 70. This is most likely malware, but let's not stop there and use another service - Any.run .
Running the file on Any.run
We see that it produces a similar result (see in the lower right corner). In addition, you can collect additional data about what the program was doing. Namely:
So, two services have already confirmed that this is malware. Let's continue. Let's use a tool called DIE.
Opening the file with DIE
Detect it easy (DIE) is a utility that allows you to import and export a list of resources, retrieve the manifest and software version, and view entropy calculations. It is possible to add your own detection algorithms or modify existing ones. This is done through scripting in a language that resembles JavaScript.
As you can see in the screenshot, the malware is written in Visual Basic. You can easily google the structure of Visual Basic 6.0 programs and a description of how they work. In short, they run in a virtual environment, which means that we need to catch the moment when this code will be unpacked in memory. You can also analyze the structure of the file and get the name of the project, used forms and other data.
Another way to find out if the malware is written in Visual Basic is to use the CFF Explorer.
CFF Explorer is a set of tools with a single minimalistic interface that allows you to view and, if necessary, edit all sections of the header of an executable file. Here you can also see imports and exports of functions from libraries, a list of the libraries themselves and the addressing of sections.
File import table in CFF Explorer
In this case, we will see a characteristic imported library - its presence indicates that Visual Basic functions are used.
The next step is to launch Hiew and, going to the beginning of the executable code, we find a function call from the library.
Hiew is a binary editor with built-in disassembler for x86, x86-64 and ARM. They can also open physical and logical drives as a file. Hiew is a "lightweight" (as opposed to IDA) and at the same time very powerful program that allows you to get a first impression of the object under study.
Viewing content in a Hiew file
At this stage, it is enough for us to know that the code in Visual Basic will be executed at startup.
It's time to try pulling out the code and capturing the startup behavior. To do this, we need a prepared virtual machine with Windows, Process Dump and API Monitor.
API Monitor is a program that allows you to monitor calls to API functions by applications and services on Windows, intercepts information about the launch of applications, or connects to a running process to view used libraries and API calls.
Run Sample.exe in the API Monitor and get the following picture: another process starts, after which the first one ends, then the program is added to startup.
We find the specified executable file, this is the original file written to the user's directory.
Found a copy at startup, on disk, open the file in DIE
The program also disables the ability to call the task manager.
Viewing file API calls using API Monitor
This is already enough to say with certainty that the file is malicious.
Let's unload a running process from RAM. Let's use a utility for dumping a process dump - Process Dump. We take the PID from the API Monitor data, it is displayed next to the process name.
Using the Process Dump utility
As a result, all libraries used by the application will be unloaded. We also find that in the address space, in addition to the main executable file, there are also hidden ones, this can be seen below, the file name contains the word hiddenmodule.
The result of the Process Dump utility
We check each received executable file in DIE.
Opening each file in DIE
We see that two of the three files are written in C ++, and one in VB.NET.
Let's pay attention to the application written in VB.NET. It can be opened with any .NET debugger, such as dnSpy. And we will get readable code in Visual Basic, all that remains is to remove obfuscation. In this case, the algorithm was complicated by adding a lot of code jumps using the GoTo command.
Let's use the IDA disassembler to analyze the two remaining files.
IDA is a popular interactive disassembler from Hex-Rays. Has a free and trial version, which is quite enough for the initial acquaintance. The company is also releasing a Pro version. The main task of the program is to translate executable files from a binary form into readable assembly code.
View Code in IDA
As you can see from the example, IDA allows you to get the program code in assembler, but for a more convenient viewing and initial evaluation, you can use the Snowman plugin and get the pseudocode.
Viewing pseudocode in IDA
Using pseudocode makes the analysis easier, but does not always give the expected result. Disassembly and pseudocode generation are automatic, and virus writers have techniques to complicate them. Such is the eternal confrontation between sword and shield, the intelligence of the malware creator and the intelligence of the virus analyst.
When we used API Monitor, we have already identified the malicious nature of this file by the actions performed. But so far we do not know what the potential of this malware is. To get a complete algorithm for the operation of this executable file, it is necessary to delve into the analysis of both assembly code and Visual Basic programs, but this is beyond the scope of this article.
Conclusion
If you get the impression that we dropped the research at the very beginning of the path, then it is partly true: here we have done only those actions that do not require knowledge of assembler. However, as you can see, it is quite possible to carry out an express analysis and establish what can be expected from malware without it.
Full parsing will require a deep understanding of the principles of the operating system and, of course, knowledge of the assembler.
If you seriously decided to take the path of a virus analyst, then the literature on reverse engineering, malware analysis, system programming and assembler, as well as practice, a lot of practice will help you. I recommend solving cracks and registering at hybrid-analysis.com to get examples of working malware. A long way awaits you, but the road will be mastered by the one walking!
xakep.ru
So, let's imagine for a start that we have an infected machine on our hands. The first step is to perform three main steps: isolate the computer from others on the network, take a memory dump, and take a disk image.
When disconnecting an infected computer from the network, it is worth remembering that if we are dealing with an encryption virus, then there is a chance of losing user data. Malware can start encrypting them when the connection to the network is interrupted, so the first thing to do is assess how important the data on the infected PC is and whether it is worth the risk.
It would be best to create a virtual network (VLAN) for quarantine with Internet access and move the infected PCs there. In a large company, this will require the coordinated actions of cybersecurity employees and network administrators, in a small company, the versatile skills of a single sysadmin.
Next, you need to take a memory dump. This is done from the very beginning, because when copying the hard disk, you will need to turn off the computer and the contents of the RAM will be lost. It is best to run the program that takes the dump from an external media, so as not to leave unnecessary traces on the hard disk - we will need the data from it unchanged.
To prevent malware from reacting to system shutdown, the easiest way is to pull out the power cable. The method, of course, is barbaric, but it guarantees an instant shutdown. Keeping data on the hard drive intact is more important to us than worrying about the health of other components.
Next, we start the PC using bootable media with any operating system in forensic mode and software to get an image of the hard disk. The most commonly used disk image is E01 (Encase Image File Format). It is supported by a large number of applications for both Windows and Linux.
INFO
Forensic mode is booting without mounting physical disks. This allows you to exclude the introduction of any changes to the investigated disk. Forensic professionals also use devices to block any attempts to access the disc for recording.
Examining dumps
Memory and disk dumps most likely contain everything we need - the body of the malicious program and the traces left by it. We can start searching.
I recommend starting by examining the copy of the disk, and using the memory dump if you cannot find any traces on the disk, or as an additional source. When analyzing the contents of the disk, first of all, we pay attention to the startup, the task scheduler and the initial boot sector of the disk.
The Microsoft website has documentation on autoloading services and libraries.
To understand how the malware got into the computer, it is worth examining the time of creation and modification of files on the disk, browser history, and user's mail archive. If you manage to establish at least an approximate time of infection, then this will be a plus. There are quite good collections of paths in the file system and registry on the Internet that you should pay attention to first.
You can also extract some unique information from the memory dump, for example, what documents and browser tabs were opened at the time of infection, what were the active network connections, work processes (including hidden ones).
File analysis
When you have a suspicious file in your hands, you will need to somehow make sure that this is an instance of a malicious program. Of course, if it is a known virus, then it can be detected by an antivirus (there is a website virustotal.com for checking all antivirus engines at once). But more and more often we come across unique cases that are not detected by antivirus programs. Such malicious programs have the FUD (Fully UnDetectable) status.
Also, it cannot be ruled out that you are faced with a zero-day threat - one that no one knows about yet (and the developers have zero days to eliminate it - hence the name). Malvar, which exploits zirodei and has the FUD status, poses a serious threat not only to individual computers, but also to entire companies.
Before starting the analysis of a suspicious file, you must do the following.
- Prepare a test bench - a virtual machine with an installed operating system suitable for launching the file under study.
- Configure access to the Internet, preferably ensuring that your real IP address is hidden so as not to lose connection with the malware's control servers (you may be recognized as a virus analyst and restricted access to hide some functions).
- Take a snapshot of the primary state of the virtual machine.
INFO
Under no circumstances connect the stand to the corporate network - this can cause massive infection of other computers.
There are two approaches to software analysis - dynamic and static. As a rule, for the best effect, a method that is more suitable for the situation is used, or both methods at the same time. For example, it may be necessary to examine the behavior of a malicious program to identify characteristic markers without analyzing algorithms. Therefore, the choice of methods and tools may change during the analysis.
Static analysis
Let's start with static analysis, as it does not require you to run malicious code and will definitely not cause an infection on your computer.
Let's take a look at the initial headers of a Windows executable.
1. DOS header file, also known as DOS stub. Thanks to it, it is possible to run a program in DOS (usually the message This program cannot be run in DOS mode is displayed). You can see the beginning of the title by the characteristic letters MZ
Executable file header
2. Immediately after the first is the header used by modern OSes with all the necessary parameters for the executable file (for example, offset to the import / export table, the beginning of the executable code section). The beginning of the title can be found by the characteristic letters PE, and a description of the format is available on the Microsoft website .
We can say that the header of the executable file contains a guide about where and what exactly is inside the file itself, what permissions should be granted to sections, all settings for correct operation, so analysis of the header can provide valuable initial information.
In addition, you need to see if there are any string data in the files. From them, you can subsequently identify such files or even get important information like the addresses of management servers.
Malware developers are always faced with the task of masking their creation as much as possible and complicating detection and analysis in every possible way. Therefore, packers for executable files are very often used.
INFO
Packers are utilities for compressing and encrypting executable files. They are used not only by malware creators, but also by developers of legitimate software to protect their programs from being hacked. Self-written packers, specially designed to complicate analysis, are not always detected by programs and require additional actions from the analyst to remove the packaging.
A deeper (and at the same time, complex) analysis of any executable files is the use of disassemblers. Assembler code is more understandable for humans than machine code, but because of the volume, it can be far from easy to understand. In some cases, it is possible to restore the source code of programs in a high-level language by decompilation - if it is possible to determine which compiler and obfuscation algorithm were used.
Glossary of terms
- Disassemblers are programs for translating machine code into a relatively readable and understandable assembly language.
- Decompilation - restoring the source code of a program in the original programming language.
- Obfuscation - changing the source code of a program so that its functionality is preserved, but it itself becomes more complicated and adds nothing garbage in it.
- Obfuscators are programs for automating obfuscation.
- Pseudocode - as a rule, this is the name of an informal language for describing algorithms, which allows you to represent the code under study in assembler in a more readable form. When translated into pseudocode, insignificant elements of the algorithm are discarded.
Assembler code
Pseudocode
Dynamic analysis
Reading pseudo-code or assembly language is like untangling a ball of thread - painstaking and time-consuming. Therefore, you can use another type of analysis - dynamic. Dynamic analysis involves launching an executable file and tracking its actions, such as accessing registry branches, sending and receiving data over the network, and working with files.
WARNING
Dynamic analysis involves launching the file under investigation. This must be done on a virtual machine that is isolated from other computers to avoid the possibility of malware spreading over the network.
You can analyze the behavior of a program by monitoring and intercepting the launch of applications at the OS level, or by connecting to a running process and intercepting calls to libraries and APIs. And in order to analyze in detail the process of program execution, it is best to use one of the debuggers.
INFO
Debugger is a utility or set of utilities that is used to test and debug the target application. The debugger can simulate the work of the processor, and not run the program on real hardware. This gives a higher level of control over execution and allows you to stop the program under specified conditions. Most debuggers are also capable of stepping through the execution of the code under study.
It doesn't matter if you use a debugger or some program that allows you to control API calls, you have to work in manual mode. This means that in-depth knowledge of the operating system is required, but you will receive the most complete data about the object of study.
However, the analysis can also be automated. For this, the so-called sandboxes are used - test environments for running software.
Sandboxes are divided into two types: offline and online. To get the most complete picture, I recommend using multiple data sources at once and not excluding any of the sandbox types. The more information you collect, the better.
Analysis example
Since malware analysis always depends on practical skills, this article would be incomplete without demonstrating it with an example. We will carry out an express analysis and establish the nature of the executable file.
First, let's define the sequence of actions. Here's what we need to do:
- get a hash sum from a file;
- use an online service to check the file;
- collect static data from a file;
- check the file in the sandbox (local or on the Internet);
- run the file in a virtual environment to track the actions being performed;
- remove the shells and get the malware deployed in memory;
- parse the code in a disassembler.
To store the file, I recommend that the first thing to do is to change the extension, for example to Sample._exe, in order to avoid accidental startup. We take a snapshot of the virtual machine on which we will run the executable file (the initial state of the system to us still come in handy), and calculate the hash sum of the file.
Getting the hash sum of a file
Let's copy the result and use virustotal.com for verification.
Checking the hash sum on virustotal.com
As you can see from the screenshot above, the VT verdict is 54 out of 70. This is most likely malware, but let's not stop there and use another service - Any.run .
Running the file on Any.run
We see that it produces a similar result (see in the lower right corner). In addition, you can collect additional data about what the program was doing. Namely:
- after the start, I duplicated myself in my memory;
- contacted server 208.91.199.224 via port 587. On the platform, you can view a network dump of interaction with the malware's control server (they are often called Command & Control, C2 or C&C);
- added a ban on starting the task manager;
- copied itself to a separate user directory;
- added itself to startup.
So, two services have already confirmed that this is malware. Let's continue. Let's use a tool called DIE.
Opening the file with DIE
Detect it easy (DIE) is a utility that allows you to import and export a list of resources, retrieve the manifest and software version, and view entropy calculations. It is possible to add your own detection algorithms or modify existing ones. This is done through scripting in a language that resembles JavaScript.
As you can see in the screenshot, the malware is written in Visual Basic. You can easily google the structure of Visual Basic 6.0 programs and a description of how they work. In short, they run in a virtual environment, which means that we need to catch the moment when this code will be unpacked in memory. You can also analyze the structure of the file and get the name of the project, used forms and other data.
Another way to find out if the malware is written in Visual Basic is to use the CFF Explorer.
CFF Explorer is a set of tools with a single minimalistic interface that allows you to view and, if necessary, edit all sections of the header of an executable file. Here you can also see imports and exports of functions from libraries, a list of the libraries themselves and the addressing of sections.
File import table in CFF Explorer
In this case, we will see a characteristic imported library - its presence indicates that Visual Basic functions are used.
The next step is to launch Hiew and, going to the beginning of the executable code, we find a function call from the library.
Hiew is a binary editor with built-in disassembler for x86, x86-64 and ARM. They can also open physical and logical drives as a file. Hiew is a "lightweight" (as opposed to IDA) and at the same time very powerful program that allows you to get a first impression of the object under study.
Viewing content in a Hiew file
At this stage, it is enough for us to know that the code in Visual Basic will be executed at startup.
It's time to try pulling out the code and capturing the startup behavior. To do this, we need a prepared virtual machine with Windows, Process Dump and API Monitor.
API Monitor is a program that allows you to monitor calls to API functions by applications and services on Windows, intercepts information about the launch of applications, or connects to a running process to view used libraries and API calls.
Run Sample.exe in the API Monitor and get the following picture: another process starts, after which the first one ends, then the program is added to startup.
We find the specified executable file, this is the original file written to the user's directory.
Found a copy at startup, on disk, open the file in DIE
The program also disables the ability to call the task manager.
Viewing file API calls using API Monitor
This is already enough to say with certainty that the file is malicious.
Let's unload a running process from RAM. Let's use a utility for dumping a process dump - Process Dump. We take the PID from the API Monitor data, it is displayed next to the process name.
Using the Process Dump utility
As a result, all libraries used by the application will be unloaded. We also find that in the address space, in addition to the main executable file, there are also hidden ones, this can be seen below, the file name contains the word hiddenmodule.
The result of the Process Dump utility
We check each received executable file in DIE.
Opening each file in DIE
We see that two of the three files are written in C ++, and one in VB.NET.
Let's pay attention to the application written in VB.NET. It can be opened with any .NET debugger, such as dnSpy. And we will get readable code in Visual Basic, all that remains is to remove obfuscation. In this case, the algorithm was complicated by adding a lot of code jumps using the GoTo command.
Let's use the IDA disassembler to analyze the two remaining files.
IDA is a popular interactive disassembler from Hex-Rays. Has a free and trial version, which is quite enough for the initial acquaintance. The company is also releasing a Pro version. The main task of the program is to translate executable files from a binary form into readable assembly code.
View Code in IDA
As you can see from the example, IDA allows you to get the program code in assembler, but for a more convenient viewing and initial evaluation, you can use the Snowman plugin and get the pseudocode.
Viewing pseudocode in IDA
Using pseudocode makes the analysis easier, but does not always give the expected result. Disassembly and pseudocode generation are automatic, and virus writers have techniques to complicate them. Such is the eternal confrontation between sword and shield, the intelligence of the malware creator and the intelligence of the virus analyst.
When we used API Monitor, we have already identified the malicious nature of this file by the actions performed. But so far we do not know what the potential of this malware is. To get a complete algorithm for the operation of this executable file, it is necessary to delve into the analysis of both assembly code and Visual Basic programs, but this is beyond the scope of this article.
Conclusion
If you get the impression that we dropped the research at the very beginning of the path, then it is partly true: here we have done only those actions that do not require knowledge of assembler. However, as you can see, it is quite possible to carry out an express analysis and establish what can be expected from malware without it.
Full parsing will require a deep understanding of the principles of the operating system and, of course, knowledge of the assembler.
If you seriously decided to take the path of a virus analyst, then the literature on reverse engineering, malware analysis, system programming and assembler, as well as practice, a lot of practice will help you. I recommend solving cracks and registering at hybrid-analysis.com to get examples of working malware. A long way awaits you, but the road will be mastered by the one walking!
xakep.ru
