141 lines
6.7 KiB
Markdown
141 lines
6.7 KiB
Markdown
# Malware Analysis Techniques
|
||
|
||
### Basic Static Analysis
|
||
|
||
- Examining the executable file without viewing the actual instructions
|
||
- This can confirm whether a file is malicious
|
||
- Provide information about its functionality
|
||
- Provide information that will allow us to produce network signatures
|
||
- Basic static analysis is straightforward and quick
|
||
- However is largely ineffective against sophisticated malware.
|
||
|
||
##### Techniques
|
||
|
||
- Using **antivirus tools** to confirm maliciousness
|
||
- virus total is an online tool to scan files for known malware
|
||
- Using **hashes** to identify malware
|
||
- When the file is run through a hashing algorithm (often `md5` or `SHA-1`) it uniquely identifies it.
|
||
- This is useful to see if other malware analysts have seen this malware
|
||
- Gleaning information from a **file’s strings**, functions and headers
|
||
- Note: microsoft uses the term wide character to describe its implementation of Uni-code strings.
|
||
- Strings can return
|
||
- IP addresses to where the malware is sending/receiving
|
||
- Windows system calls like `GetLayout` & `SetLayout` which are used in windows graphics library
|
||
- Windows libraries such as `GDI32.DLL` which is a graphics library.
|
||
- Therefore we can infer this malware opens a GUI display
|
||
- Note: strings will show the executable’s manifest at the end, a brief `xml` file.
|
||
|
||
### Basic Dynamic Analysis
|
||
|
||
- Running the malware and observing its behaviour on the system in order to:
|
||
- remove the infection
|
||
- produce effective signatures
|
||
- Is important to note that a safe environment should be set up, so that the malware can be run without risk of damage to your system or network
|
||
- Like basic static analysis, this can be useful but can miss important functionality
|
||
|
||
### Advanced Static Analysis
|
||
|
||
- Reverse-engineering the malware’s internals by loading the executable into a disassembler
|
||
- This involves looking at the instructions to discover what the malware does
|
||
- This requires an in-depth knowledge of disassembly, code constructs and windows operating system constructs
|
||
|
||
#### Problems with Static Analysis
|
||
|
||
- Only shows us what is in the program
|
||
- Not how it is used (if it used at all)
|
||
- Might see potential filename - but is that file created or deleted
|
||
- Does it get used every time the program is run or under certain circumstances
|
||
- Unsure of sequence of events
|
||
- Just because we can’t see something, doesn’t mean the program doesn’t do it
|
||
|
||
### Advanced Dynamic Analysis
|
||
|
||
- Running the malware in a debugger to examine the internal state.
|
||
- Allows you to see internal states of variables and how the program uses memory over time.
|
||
|
||
### Packed and Obfuscated Malware
|
||
|
||
Malware writers often use packing or obfuscation to make malware files more difficult to detect or analyse.
|
||
|
||
**Obfuscated** programs are ones whose execution the malware author has attempted to hide
|
||
|
||
- This can be done by changing variable names, minifying code
|
||
|
||
**Packed** programs are a subset of obfuscated programs, in which the malware is compressed and cannot be analysed.
|
||
|
||
- This stops us from being able to read strings from the program
|
||
- If running strings on a program yields little information, the program is probably packed and therefore malicious.
|
||
|
||
> Packed and obfuscated code will often include at least the functions `LoadLibrary` and `GetProcAddress`, which are used to load and gain access to additional functions.
|
||
|
||
#### Packing Files
|
||
|
||
When the packed program is run, a small wrapper program also runs to decompress the packed file and then run the unpacked file.
|
||
|
||
- When a packed program is analysed statically, only the small wrapper program can be dissected
|
||
|
||
|
||
|
||
- Programs like `PEiD` can be used to ascertain whether the file has been packed or not
|
||
|
||
### Linked Libraries and Functions
|
||
|
||
One of the most useful pieces of information we can gather about a program is the list of functions that it imports.
|
||
|
||
- Code libraries can be connected to the main executable by *linking*
|
||
- Code libraries can be linked statically, at runtime or dynamically
|
||
|
||
##### Static Linking
|
||
|
||
When a library is statically linked, all code from that library is copied into the executable which makes the executable grow in size.
|
||
|
||
- It is difficult to differentiate between the programs code and the imported code as nothing in the PE header suggests the file contains linked code
|
||
- This is the most uncommon method of linking
|
||
|
||
##### Run-time Linking
|
||
|
||
- Run-time linking is commonly used by malware, especially when packed or obfuscated
|
||
- Executable files connect to libraries only when that function is needed, **not at program start**
|
||
- `GetProcAddress` and `LoadLibrary` allow the program to access any function in any library on the system.
|
||
- This means when functions are used, we cannot tell statically which functions are linked.
|
||
|
||
##### Dynamic Linking
|
||
|
||
When libraries are dynamically linked, the host OS searches for necessary libraries when the program is loaded.
|
||
|
||
- The PE file header stores information about every library that will be loaded and every function that will be used by the program
|
||
|
||
#### Commonly linked DLLs
|
||
|
||
- `Kernel32.dll`
|
||
- Very common library contains core functionality such as access & manipulation of memory, files and hardware.
|
||
- `User32.dll`
|
||
- This `DLL` contains all the user-interface components such as buttons, scrolling etc
|
||
|
||
#### Common imported functions
|
||
|
||
The PE file header also includes information about specific functions used by an executable. The names alone will give clues however microsoft documents everything on MSDN
|
||
|
||
- `FindFirstFileW`, `FindNextFileW`, `FindClose`
|
||
- These all involve searching the users system for files
|
||
- `FindFirstFileW` will include a string for regex, so we can see if its searching for all files `./*` or a specific `myFile.exe`
|
||
- `ReadFile`, `WriteFile`
|
||
- `SetWindowsHookExW`
|
||
- Often used to implement keylogs
|
||
- `CreateWindowExW`, `DefWindowProcW`, `getWindowsTextW`, `setWindowsTextW` etc
|
||
- This relates to setting up a GUI
|
||
- `RegisterHotkey`
|
||
- Find what this keypress is, to see what it does
|
||
|
||
#### PE Header Summary
|
||
|
||
| Field | Information Revealed |
|
||
| --------------- | ------------------------------------------------------------ |
|
||
| Imports | Functions from other libraries that are used by the malware |
|
||
| Exports | Functions in the malware that are meant to be called by other programs or libraries |
|
||
| Time Date Stamp | Time when the program was compiled |
|
||
| Sections | Names of sections in the file and their sizes on disk and in memory |
|
||
| Subsystem | Indicates whether the program is a command-line or GUI application |
|
||
| Resources | Strings, icons, menus |
|
||
|