# 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, it is largely ineffective against sophisticated malware.

##### Techniques

- Using **antivirus tools** to confirm maliciousness
    - VirusTotal 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 Unicode strings.
    - Strings can return
        - IP addresses to where the malware is sending/receiving
        - Windows system calls like `GetLayout` & `SetLayout` which are used in the 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
- It 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 is 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

![1645731141.png](img/1645731141.png)

- 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 program’s 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 user’s system for files
    - `FindFirstFileW` will include a string for regex, so we can see if it’s 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                                        |