Basic Static Analysis

13 min read

Antivirus Scanning

When first analyzing prospective malware, a good first step is to run it through multiple antivirus programs, which may already have identified it. But antivirus tools are certainly not perfect. They rely mainly on a database of identifiable pieces of known suspicious code ( file signatures), as well as behavioral and pattern-matching analysis (heuristics) to identify suspect files. One problem is that malware writers can easily modify their code, thereby changing their program’s signature and evading virus scanners. Also, rare malware often goes undetected by antivirus software because it’s simply not in the database.

Hashing: A Fingerprint for Malware

Hashing is a common method used to uniquely identify malware. The malicious software is run through a hashing program that produces a unique hash that identifies that malware (a sort of fingerprint).

Tools to get hash:

  1. md5deep
  2. WinMD5

Once you have a unique hash for a piece of malware, you can use it as follows:

  • Use the hash as a label.
  • Share that hash with other analysts to help them to identify malware.
  • Search for that hash online to see if the file has already been identified.

Finding Strings

Searching through the strings can be a simple way to get hints about the functionality of a program. For example, if the program accesses a URL then you will see the URL accessed stored as a string in the program.

We can use Strings program to search strings in a executable.

NOTE

Both ASCII and Unicode formats store characters in sequences that end with a NULL terminator.

Example:
ASCII representation of the string BAD

Unicode representation of the string BAD

Packed and Obfuscated Malware

  • Obfuscated programs are ones whose execution the malware author has attempted to hide.
  • Packed programs are a subset of obfuscated programs in which the malicious program is compressed and can not be analyzed.

Hint

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.

  • One way to detect packed files is with the PEiD program. You can use PEiD to detect the type of packer or compiler employed to build an application, which makes analyzing the packed file much easier.

Linked Libraries and Functions

One of the most useful pieces of information that we can gather about an executable is the list of functions that it imports. Imports are functions used by one program that are actually stored in a different program, such as code libraries that contain functionality common to many programs. Code libraries can be connected to the main executable by linking.

Static, Runtime, and Dynamic Linking

Static linking

  • Static linking is a process where all external libraries required by a program are combined into the final executable file at compile time. This means that all the code needed to run the program is included in one file.
  • Advantages:
    • No need for external dependencies at runtime.
    • Faster execution as all symbols are resolved before execution.
  • Disadvantages:
    • Larger executable size since all libraries are included.
    • Updating libraries requires recompiling the application.

Runtime linking

  • Runtime linking involves loading and linking external libraries during the execution of the program, rather than at compile time. This is typically achieved using functions like LoadLibrary() in Windows or dlopen() in Unix-based systems.
  • Advantages:
    • Smaller executable size as libraries are not included in the executable.
    • More flexibility since different versions of libraries can be loaded at runtime.
  • Disadvantages:
    • Slightly slower execution due to runtime symbol resolution.
    • Potential for runtime errors if the required libraries are not found.

Dynamic linking

  • Dynamic linking loads external libraries when the program is launched (load time) or during execution (runtime). The executable contains references to shared libraries rather than the actual code.
  • Advantages:
    • Smaller executable size as shared libraries are loaded separately.
    • Easy to update libraries without recompiling the application.
  • Disadvantages:
    • Dependency on external shared libraries being present on the system.
    • Potential version conflicts (known as “DLL Hell” in Windows).

In short,

  • Static Linking: All required libraries are included at compile time → Larger executable, no external dependencies.
  • Runtime Linking: Libraries are loaded during execution → More flexibility but risk of runtime errors.
  • Dynamic Linking: Libraries are linked at load time or runtime → Smaller executable, external dependencies required.

To list dynamically linked functions in an executable, try Dependency Walker.

Hint

A program’s DLLs can tell you a lot about its functionality. See lists of Headers, DLLs and Functions.

The PE File Headers and Sections

The PE file format contains a header followed by a series of sections. The header contains metadata about the file itself. The following are the most common and interesting sections in a PE file:

.text

  • The .text section contains the instructions that the CPU executes. All other sections store data and supporting information. Generally, this is the only section that can execute, and it should be the only section that includes code.

.rdata

  • The .rdata section typically contains the import and export information. This section can also store other read-only data used by the program. Sometimes a file will contain an .idata and .edata section, which store the import and export information.

.data

  • The .data section contains the program’s global data, which is accessible from anywhere in the program. Local data is not stored in this section, or anywhere else in the PE file.

.rsrc

  • The .rsrc section includes the resources used by the executable that are not considered part of the executable, such as icons, images, menus, and strings. Strings can be stored either in the .rsrc section or in the main program, but they are often stored in the .rsrc section for multilanguage support.

In Short,

ExecutableDescription
.textContains the executable code
.rdataHolds read-only data that is globally accessible within the program
.dataStores global data accessed throughout the program
.idataSometimes present and stores the import function information; if this section is not present, the import function information is stored in the .rdata section
.edataSometimes present and stores the export function information; if this section is not present, the export function information is stored in the .rdata section
.pdataPresent only in 64-bit executables and stores exception-handling information
.rsrcStores resources needed by the executable
.relocContains information for relocation of library files

We can Examine PE File with PEview

Note

The compile time is a bit problematic. All programs with a compile time June 19, 1992 is Delphi program. If you see that compile time, you’re probably looking at a Delphi program, and you won’t really know when it was compiled.

Hint

The IMAGE_OPTIONAL_HEADER section includes several important pieces of information. The Subsystem description indicates whether this is a console or GUI program. Console programs have the value IMAGE_SUBSYSTEM_WINDOWS_CUI and run inside a command window. GUI programs have the value IMAGE_SUBSYSTEM_WINDOWS_GUI and run within the Windows system.

Example:

As you can see in output my PEview, the .text, .rdata, and .rsrc sections each has a Virtual Size and Size of Raw Data value of about the same size. The .data section may seem suspicious because it has a much larger virtual size than raw data size, but this is normal for the .data section in Windows programs. But note that this information alone does not tell us that the program is not malicious; it simply shows that it is likely not packed and that the PE file header was generated by a compiler.

PE Header Summary

FieldInformation reveled
ImportsFunctions from other libraries that are used by the malware
ExportsFunctions in the malware that are meant to be called by other programs or libraries
Time Date StampTime when the program was compiled
SectionsNames of sections in the file and their sizes on disk and in memory
SubsystemIndicates whether the program is a command-line or GUI application
ResourcesStrings, icons, menus, and other information included in the file

LABS

LAB 1-1

  1. Upload the files to http://www.VirusTotal.com/ and view the reports. Does either file match any existing antivirus signatures?
    Ans.


    Yes both file match to many antivirus signatures.

  2. When were these files compiled?
    Ans.

    As we can see both file were compiled at 10th Dec, 2010 at 16:16 UTC.

  3. Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?
    Ans.


    This files were compiled with Microsoft visual C++ 6.0 & there is no sign of any packed or obfuscated file.

  4. Are there any other files or host-based indicators that you could look for on infected systems?
    Ans.

    As we can see in the images above, the functions CopyFileA, FindFirstFileA, FindNextFileA, etc., from KERNEL32.DLL were imported in LAB01-01.EXE, while Sleep, CreateProcessA, and other functions from KERNEL32.DLL were imported in LAB01-01.DLL. These imports appear suspicious. Additionally, WS2_32.DLL is present, indicating that the DLL is utilizing network-related functions.
    Refer to Headers, DLLs and Functions for more information about the functionality and working of this functions and DLLs.

  5. Are there any other files or host-based indicators that you could look for on infected systems?
    Ans.

strings.exe Lab01-01.exe


The strings found in LAB01-01.EXE suggest that it is searching for executables on the victim’s system. Additionally, we see references to C:\Windows\System32\Kernel32.dll and C:\Windows\System32\kerne132.dll. This indicates that kerne132.dll is designed to mimic the legitimate kernel32.dll file. As a result, kerne132.dll can serve as a host-based indicator for detecting infections and should be analyzed further for potential malicious code.

  1. What network-based indicators could be used to find this malware on infected machines?
    Ans.

    The imports and strings in LAB01-01.DLL suggest backdoor functionality. It imports functions from WS2_32.DLL by ordinal, making it unclear which ones are used. Notably, it imports CreateProcess and Sleep from KERNEL32.DLL, which, along with the strings exec and sleep, indicate that the backdoor likely executes commands over a network and can pause its execution when instructed.
    Refer to Headers, DLLs and Functions for more information about the functionality and working of this functions and DLLs.

  2. What would you guess is the purpose of these files?
    Ans.
    LAB01-01.EXE appears to search for executables, while LAB01-01.DLL functions as a backdoor, enabling remote command execution via CreateProcess and Sleep. The fake kerne132.dll suggests evasion tactics, and network-related imports indicate potential remote control capabilities.

LAB 1 -2

  1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?
    Ans.

    Yes

  2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.
    Ans.

    Select Options > Hardcore Scan > Save.

    Thus the scan say that this exe is UPX-packed.
    Unpacking it with UPX.
    1. Download UPX - here
    2. Open cmd.
    3. Navigate to the upx download directory
    4. Use command .\upx.exe -d originalfile -o outputfilename

  3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?
    Ans.



    Command: strings.exe LAB2.exe
    The imports from KERNEL32.DLL and MSVCRT.DLL are common and provide little insight. However, WININET.DLL imports (InternetOpen, InternetOpenURL) indicate internet connectivity, while ADVAPI32.DLL (CreateService) suggests service creation. The string www.malwareanalysisbook.com is likely accessed via InternetOpenURL, and Malservice could be the created service’s name.

  4. What host- or network-based indicators could be used to identify this malware on infected machines?
    Ans.
    We can’t determine exactly what this program is doing just from static analysis. To gain more insights, we would need to run it on an infected system and analyze its behavior and network traffic. However, since we are performing basic static analysis, running the program is not part of our approach.

LAB 1 -3

  1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?
    Ans.

    Yes, 64/72 security vendors flagged this file as malicious.

  2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.
    Ans.

    It shows that exe is packed with FSP 1.0 .
    To unpack it follow this steps:
    1. Download unipacker using command: pip3 install unipacker

    2. Launch unipacker and Enter path to the Lab01-03.exe.

    3. Enter r to unpacked exe.

    The unpacked exe will be saved as unpacked.exe in same directory.

  3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?
    Ans.


    The imports ole32.dll, oleaut32.dll, and msvcrt.dll suggest that the program interacts with COM objects and uses OLE automation (ole32.dll and oleaut32.dll). The presence of msvcrt.dll indicates the program is likely written in C or C++ and relies on standard runtime functions. Additionally, the use of kernel32.dll for memory management functions (like VirtualAlloc and VirtualFree) implies dynamic memory manipulation, often seen in packed or obfuscated code, potentially indicating malware behavior.

  4. What host- or network-based indicators could be used to identify this malware on infected machines?
    Ans.
    Can’t find anything useful.

LAB 1-4

  1. Upload the Lab01-04.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?
    Ans.

    Yes, 64/73 security vendors flagged this file as malicious.

  2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.
    Ans.

    This files were compiled with Microsoft visual C++ 6.0 & there is no sign of any packed or obfuscated file.

  3. When was this program compiled?
    Ans.

    As we can see in above image that LAB01-04.exe is compiled on 30-08-2019 at 22:26:69 UTC.

  4. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?
    Ans.

    The imports from advapi32.dll suggest that the program is managing permissions. Meanwhile, the imports from WinExec and WriteFile, coupled with the results from Dependency Walker, reveal that the program writes a file to disk and subsequently executes it. Additionally, there are imports for retrieving data from the file’s resource section.

  5. What host- or network-based indicators could be used to identify this malware on infected machines?
    Ans.

    The string \system32\wupdmgr.exe suggests that this program may create or alter a file at that location. The string www.malwareanalysisbook.com/updater.exe likely points to the location where additional malware is stored, awaiting download.

  6. This file has one resource in the resource section. Use Resource Hacker to examine that resource, and then use it to extract the resource. What can you learn from the resource?
    Ans.


    Resource Hacker identifies the resource type as binary, indicating arbitrary binary data. Upon examining the data, most of it appears meaningless. However, we notice the string “!This program cannot be run in DOS mode,” which is the error message found in the DOS header of all PE files. This suggests that the resource contains an additional executable file stored within the resource section of Lab01-04.exe. This is a common technique used in malware.
    To continue analyzing the file with Resource Hacker, we select Action → Save resource as binary file. After saving the resource, we open the file in PEview to further investigate the embedded file. Upon reviewing the imports, we observe that the embedded file makes network-related calls, specifically using URLDownloadToFile, a function often utilized by malicious downloaders. It also calls WinExec, likely to execute the downloaded file.

Graph View

Recently Added