notes/docs/lectures/malware/01_static_analysis.md

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

• 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