Basic Static Analysis Flashcards
What are some of the key aspects of Basic Static Techniques?
Basic Static Techniques (BST) are usually the first step in the analysis process. The intent is to determine the function of a piece of code or program. During such analysis the potential malware itself is not running as only the code itself is assessed.
The main goal of BST is to find Indicators of Compromise (IoC) and form a hypothesis.
What are IoCs?
IoCs are activities considered out of place which may indicate the presence of unwanted activity on a system.
Examples are:
- Unusual outbound network traffic
- Heightened volume of database reads
- Geographical irregularities
IoCs are often used for building IDS signatures. Analysis of new malware can provide valuable IoCs through thoroughly inspecting the malware’s behaviour.
How can Antivirus Scanning be utilized in Basic Static Analysis?
Performing an antivirus scan is a useful first step since the software can look for both file and behavioural signatures. As different antivirus programs utilizes different signatures it is often recommended to run more than one program.
One major downside with antivirus software is that the malware (its signature) must be known in advance for detection to occur. Consequently, antivirus software is ill-suited for detecting new types or modified malware. Behavioural or pattern-matching antivirus programs are better suited for handling new/adapted malware, which is why it is becoming more prevalent in modern antivirus software.
Why are hashes useful for detecting malware?
By hashing a potentially malicious file, you can look-up the hash value and check whether it matches the hash value of some known malware. You can also control whether a known file on the system has been tampered with (maybe the attacker has injected code into a known DLL or .exe file) by checking the file’s hash value against the known hash for the file. Any deviation would signify that the file has been tampered with.
What is the purpose of fuzzy hashing?
Changing the hash of a file is easy, as only one bit in the file must be changed to change the hash. Consequently, attackers will modify their files such that the hashes change while the functionality remain unaltered. This technique is used to lessen the likelihood of a malicious file being detected through detection of file hash value.
To combat this technique, we can use a strategy called fuzzy/piecewise hash where we look at sections of the file and their respective hash values. Such sections are typically referred to as critical bytes, e.g., system calls and other operations which are critical for the intended behaviour of the malware. A well-known tool for fuzzy hashing is ssdeep
Why are strings important for malware analysis?
Strings provide valuable clues concerning the functionality of a program. Some examples are the strings used for defining potential URLs or IP-addresses the program should connect to, or paths to locations on the system where the program should store data.
Simply listing the strings found in a program can provide in depth insight into the functionality of the program.
String inspection differs from using antivirus programs and hash values. Inspecting the strings requires the analyst to closely examine the program, whereas antivirus and hashing is more of a reference check.
What is packed malware and what is the purpose of the technique? What may indicate that a program is packed?
Packing malware is a technique where the malicious program itself is compressed (and therefore not readable). In addition to the packed malware there is also a wrapper program used for decompressing the packed code. When not decompressed, we can only perform operations such as string listing on the wrapper.
Should the packed malware be compressed using a well known packer it becomes possible to perform the decompression without running the wrapper. If we cannot decompress packed malware, we cannot perform BSA as it requires running the wrapper program, which may be dangerous if not in a safe environment.
Most malware is packed. Consequently, packing is an IoC. It does not need to be malicious, but it warrants closer inspections.
If a program only contains a small number of strings, then it is likely to be packed. This is due to only the wrapper being read.
Mention two of the strings often seen in packed/obfuscated malware
The function calls LoadLibrary and GetProcAddress are often seen in packed malware as obfuscated code tends to be quite limited and therefore requires additional functionality. These combined with a low number of strings is often considered an IoC.
What information can be found in PE files?
The Portable Executable (PE) file format used for storing information on several types of files, e.g., .exe, .o, and .DLL. PE files are used in Windows and aid the OS loader in preparing for code execution. Take for instance the PE header which contains information such as space requirements (for main memory), what kind of application the loaded program is, and what library functions to be loaded. All this information is required for any application to run and will therefore also be present for malware. The PE file can be found in the compiled code for any program.
The information found in PE headers is of great value to malware analysts.
Describe the typical content of a PE file and their importance/value
IMAGE DOS_HEADER or MS-DOS Stub are considered “historical artefacts” and therefore of little value.
The IMAGE_NT_HEADERS contain several fields:
- Signatures which are always the same (and should therefore be ignored)
- IMAGE_FILE_HEADER which contains basic info about the file. One example is a timestamp stating when the compilation occurred (This can however easily be tampered with).
- IMAGE_OPTIONAL_HEADER will at times contain useful information, such as whether the application is a console or a GUI program.
Name some of the different sections found within the IMAGE_SECTION_HEADER in a PE-file, and what they contain.
.text section contains the executable code, i.e., CPU instructions. Hence, this is a crucial section.
.rdata is read only and contains literal strings, constants, and debug information. This data is always initialized when the application is launched.
.bss contains uninitialized variables that may be initialized during execution, e.g., some variables exclusive to a function/method call which only occurs under some specific conditions (if X: use Y; else: useZ;). The .bss section is useful for reducing the size of the .text section when not run.
.data contains data not stored in either .rdata nor .bss. One example is global data/variables.
.rsrc contain resources such as strings, icons, images, and menus.
.idata contains information on the functions imported from library files such as DLLs. This section is not always present as the import data may be placed in the .rdata section.
.edata contains information on the functions implemented in the program which other applications can use. DLLs present their exportable functions (those other applications can use) in the .edata section.
.pdata contains an array of function table entries which are used for exception handling. This is only used in 64-bit executables.
.reloc contains information for relocation of library files.
Not all sections must be present for every application. The sections utilized depends on the program and its requirements.
What is a potential indicator of compromise within the IMAGE_SECTION_HEADER?
One can inspect the difference an applications virtual and raw memory size, i.e., the difference in size between the program when loaded into main memory, and on disk.
The two should be similar and a large discrepancy, i.e., the size on disk being significantly smaller than once in main memory, indicates that the program is packed (which should get your attention).
Discrepancies in the .rscr section is especially interesting as attackers have been known to hide code in this section.
Why is it important to assess the linked libraries and imported functions?
The imported functions tell us a lot about the programs functionality, i.e., what it is capable of doing. If the program imports the function URLDownloadToFile, it is likely that the program will download documents/information/instructions from an external system.
Linking is concerned with how code from libraries is connected to the main code of the program being analyzed.
What are the possible ways library functions are linked to an application importing them?
Static linking is simply copying all the code from the library and putting at the top of the application source code. Consequently, the application grows in size and it becomes difficult to distinguish between library and original code as there is no indication in the PE header.
This is less commonly used in windows programs, but common in UNIX and LINUX applications (not the focus of the course).
Runtime linking works by only fetching the imported function when it is needed. Through using the functions GetProcAddress and LoadLibrary, the program can load functions not listed in the file header. This is commonly used in packed or obfuscated malware since it makes it impossible to tell which functions are linked to the program when using static analysis. This not common in benign software.
Dynamic linking is the most common method. Here the host OS searches for the necessary libraries when the program is loaded. This is carried out through inspecting the PE file header which stores information on the required libraries and the functions needed.
