Skip to content

Malware_Analysis_Report.md

Latest commit

 

History

History
140 lines (103 loc) · 18.5 KB

Malware_Analysis_Report.md

File metadata and controls

140 lines (103 loc) · 18.5 KB

Malware Analysis Report: Windows PE (SpyEye Suspected)

Analysis Date: April 22, 2025

Analyst: Idurus Adan Mohamed

Environment: Ubuntu Linux Virtual Machine (Isolated)

Malware Sample: malware.exe

Target OS: MS Windows (Identified as PE32 executable)

Suspected Type: Spyware (SpyEye based on original sample source context)

Note: Raw output files from analysis tools and commands referenced in this report are located within the Analysis_Files/ directory, under the static_analysis, dynamic_before_analysis, and dynamic_after_analysis subfolders.

1. Executive Summary

This report documents the analysis of malware.exe, a Windows executable suspected to be a SpyEye variant. Analysis was performed within an isolated Ubuntu Linux VM using standard static analysis techniques (file identification, header parsing, string analysis, import analysis, disassembly) and limited dynamic analysis. Static analysis confirmed the sample is a 32-bit Windows PE executable compiled in March 2010. Findings revealed potential capabilities for file system interaction, process/memory manipulation, and resource handling. Notably, disassembly analysis (detailed in the Analysis_Files/static_analysis/ folder) uncovered the use of dynamic API resolution via hashing, an obfuscation technique used to hide direct calls to Windows functions. Dynamic analysis on the Linux host (comparing states documented in Analysis_Files/dynamic_before_analysis/ and Analysis_Files/dynamic_after_analysis/ folders) was constrained due to the OS mismatch but highlighted temporary file activity. This report details the findings, discusses analysis challenges, and proposes a remediation strategy based on the observed static characteristics. In essence, this Windows malware likely functions as spyware, possessing the necessary components for malicious actions while employing techniques to evade basic detection, necessitating a Windows environment for comprehensive behavioural analysis.

2. Static Analysis Findings

Static analysis involves examining the malware file without executing it, using various tools and techniques to understand its structure and potential functionality. Raw data files for this section are primarily located in the Analysis_Files/static_analysis/ folder.

  • File Identification & Basic Properties: Initial checks confirmed the file type, architecture, and generated unique hashes for identification.

    • Filename: malware.exe
    • File Type: PE32 executable (GUI) Intel 80386, for MS Windows (Identified via file command output)
    • Compilation Timestamp: Thu Mar 11 12:17:10 2010 (Extracted from PE header analysis)
    • MD5 Hash: 0f37839f48f7fc77e6d50e14657fb96e (Calculated hash)
    • SHA256 Hash: f097ad77b99b3744994a646d6a3577cea2faa8b9e656fcccbbd73244e227c850 (Calculated hash)
    • Size: 82,432 bytes (File system property) These basic properties provide essential identifiers for tracking and referencing the sample.

  • PE Structure & Headers Analysis: Examination of the Portable Executable (PE) header (detailed output in Analysis_Files/static_analysis/) provides metadata about how the file is structured and intended to run on Windows.

    • Sections: Contains standard PE sections: .text (executable code, permissions: rwx), .rdata (read-only data, permissions: r--), .data (read-write data, permissions: rw-), .rsrc (resources, permissions: r--). Permissions indicate typical roles for code, data, and resources.
    • Entry Point: 0x00402309 (Relative to Image Base 0x400000). This is the address where execution nominally begins.
    • Flags: Header analysis revealed the NO_SEH (No Structured Exception Handling) flag is set, which can sometimes be seen in malware.
    • Rich Header: Data suggests compilation with Microsoft Visual Studio tools (Linker Version 8.0, etc.), providing clues about the development environment. Overall, the header information paints a picture of a standard 32-bit Windows executable compiled with common Microsoft tools around 2010, with no immediately obvious structural anomalies beyond the NO_SEH flag.

  • Imports Analysis (IAT): The Import Address Table (IAT) lists functions the malware intends to use directly from Windows libraries (DLLs). This gives strong clues about its capabilities (see IAT dump in Analysis_Files/static_analysis/). Note: As discovered via disassembly, this list is incomplete due to dynamic API resolution.

    • KERNEL32.DLL: Imports suggest core OS interactions: file I/O (CreateFileW, WriteFile, ReadFile), process/memory management (VirtualAlloc, GetProcAddress, LoadLibraryA), resource access (FindResourceA, LoadResource).
    • USER32.DLL: Imports suggest potential GUI interaction or system functions (ShowWindow, PeekMessageA, SendMessageA).
    • ntdll.dll: Imports suggest lower-level functions for memory (memcpy, memset) and string operations.
    • GDI32.DLL: Minimal import (CreateBitmap). The functions imported directly point towards capabilities necessary for common malware actions like file manipulation, memory allocation, and potentially loading additional code or resources.

  • Exports Analysis: This file exports some functions, which is less common for a standalone executable (.exe). Export details can be found in the PE analysis outputs within the Analysis_Files/static_analysis/ folder.

    • Exported Functions: _strdup, free, malloc, rand. These are standard C library functions. Their presence as exports might indicate this code was part of a larger project, compiled as a DLL initially, or statically linked parts of the C runtime it intends to expose, adding a slight peculiarity to its structure as an executable.

  • Strings Analysis: Extracting sequences of readable characters (strings) from the binary can reveal filenames, messages, URLs, configuration keys, or other artifacts (see strings output in Analysis_Files/static_analysis/).

    • Key Strings: The string config.dat was found, potentially a configuration file the malware seeks to read or write. A resource named CONFIG was also identified in the PE resource section analysis. Strings like "%s\\%s.%s.dll" suggest dynamic construction of file paths or library names.
    • Notable Omissions: No hardcoded IP addresses or URLs were found via simple string extraction.
    • Obfuscation: Many unreadable or non-ASCII strings were present, suggesting data might be encoded or encrypted within the binary. A notable string ܙVE1DD562C92E0EBBEC606170E64B39DC4 might be a hash or unique identifier. The strings analysis yielded potential configuration artifacts and hints of dynamic behaviour but lacked immediate network IOCs, suggesting communication details might be obfuscated or dynamically generated.

  • Packing/Obfuscation Check: Initial checks looked for common packing methods used to compress or obscure malware.

    • UPX: Not detected using standard UPX checks (see tool output in Analysis_Files/static_analysis/).
    • Stripped: Analysis tools indicated the file was not stripped of symbols (potentially making analysis slightly easier).
    • Primary Obfuscation: Subsequent disassembly revealed dynamic API resolution as a key obfuscation technique, meaning the malware isn't simply compressed but actively hides its core functionality.

  • Disassembly Analysis (.text section): Disassembling the executable code section translates machine instructions into human-readable assembly language, allowing for a deeper understanding of the program's logic and behaviour. (See disassembly output in Analysis_Files/static_analysis/). This is a highly technical process.

    • Code Structure: Revealed numerous functions, including complex ones with conditional logic (jne, je, etc.) and loops.
    • Dynamic API Resolution: The most significant finding was a repeated code pattern used to hide calls to Windows API functions. Instead of calling APIs directly (which would list them in the IAT), the malware appears to:
      1. Load a pre-calculated hash value representing the target API function.
      2. Call an internal resolver function (identified around address 0x402c7c in the disassembly output) with this hash.
      3. This internal function likely looks up the hash, finds the actual memory address of the target Windows API function at runtime.
      4. The malware then calls the API function using the address returned by the resolver. This technique bypasses simple static analysis of imports and requires disassembly or dynamic analysis (observing the calls as they happen) to identify the true API usage. Examples of potential hash values observed being pushed before resolution calls included 0x2d3a75e1, 0x78b00c7e, 0xa073577.
    • Inferred Functionality: Assembly code patterns suggested:
      • Initialization routines and manipulation of global state variables/flags.
      • Use of data tables and lookups.
      • Construction of file paths or module names using format strings like "%s\\%s.%s.dll".
      • Stack buffer initializations with specific patterns, potentially for cryptographic operations or preparing data structures.
    • Limitations: The disassembly output provided appears to be from a basic linear sweep and may be incomplete. Full reverse engineering would require more advanced tools and time to map out all functions, data structures, and control flow definitively. Nevertheless, the disassembly clearly demonstrated that the malware employs obfuscation to hide its Windows API calls, meaning its full capabilities are not apparent from the import table alone.

3. Dynamic Analysis Findings (Linux Environment)

Dynamic analysis involves running the malware in a controlled environment to observe its behaviour. Note: Executing this Windows malware on Linux provides very limited insight into its intended operation. System state snapshots before and after attempted execution are located in the Analysis_Files/dynamic_before_analysis/ and Analysis_Files/dynamic_after_analysis/ folders respectively.

  • Environment: Isolated Ubuntu Linux VM. Network services (HTTP, FTP, etc.) were simulated using inetsim to potentially capture connection attempts. System state (processes, disk usage, network sockets) was snapshotted before and after attempted execution. File system activity was monitored using inotifywait.
  • Observed Behaviour:
    • Process Activity: No new, persistent malicious processes were observed running after attempting to execute the Windows binary, according to process listing commands (ps aux) comparison between the 'before' (Analysis_Files/dynamic_before_analysis/) and 'after' (Analysis_Files/dynamic_after_analysis/) states. The process list remained consistent with standard system processes and the inetsim simulator.
    • Network Activity: No changes in listening network sockets were detected via ss command comparison. No outbound connection attempts were logged by inetsim (though traffic was captured to a .pcap file located in Analysis_Files/dynamic_after_analysis/ for potential future analysis, which was outside this project's scope). This is expected, as the malware likely couldn't execute properly to initiate network calls.
    • File System Activity: inotifywait logs (in Analysis_Files/dynamic_after_analysis/) showed repeated access and modification events on temporary file descriptors within the /tmp/ directory. This activity is most likely an artifact of the Linux environment attempting to handle or execute the incompatible PE file, rather than the malware's intended file operations on Windows. Disk usage (df, du outputs) showed negligible changes between the 'before' and 'after' snapshots found in the dynamic analysis folders. In summary, dynamic testing on Linux yielded no evidence of the malware executing its core logic, primarily observing system artifacts related to the OS handling an incompatible file format, thus reinforcing the need for a Windows analysis environment.

4. Challenges and Learning Points

The primary challenge was the mismatch between the malware's target OS (Windows) and the analysis environment (Linux).

  • Challenge: Inability to observe the malware's true runtime behaviour (Windows API calls, registry changes, process injection, native network communication). The effectiveness of dynamic analysis was severely limited.
  • Learning Points: This experience highlighted:
    • Environment is Key: Accurate dynamic malware analysis requires an environment that mirrors the intended target (OS version, architecture, installed software).
    • Static Analysis Importance: When dynamic analysis is impractical or limited, static techniques (especially disassembly) become critical for inferring functionality and identifying obfuscation methods.
    • Obfuscation Impact: Witnessing dynamic API resolution underscores how malware authors hide functionality, necessitating deeper analysis techniques. Ultimately, attempting to run the malware on the wrong OS was a practical lesson in the necessity of appropriate environment setup and demonstrated the value of static analysis techniques when dynamic observation is hindered.

5. Remediation Plan (Based on Static & Disassembly Findings)

This plan proposes mitigation strategies based on the characteristics identified during static and disassembly analysis (referencing data in the Analysis_Files/static_analysis/ folder). Effective remediation on a live Windows network would require validation through targeted dynamic analysis or threat intelligence correlation.

  1. IOC Blocking (Hashes): Implement blocking rules for the calculated file hashes in endpoint security solutions (AV/EDR) and network security appliances:
    • SHA256: f097ad77b99b3744994a646d6a3577cea2faa8b9e656fcccbbd73244e227c850
    • MD5: 0f37839f48f7fc77e6d50e14657fb96e
  2. System Scanning: Utilize EDR/AV tools to proactively scan Windows endpoints for files matching these hashes.
  3. Behavioural Detection Rules (EDR/Monitoring): Given the use of dynamic API resolution, focus on detecting the consequences of the malware's actions rather than specific API imports:
    • Monitor for processes creating or modifying files named config.dat.
    • Alert on unexpected processes attempting to read/load PE resources named CONFIG.
    • Flag suspicious file creation/modification in common user/temporary directories by unsigned or untrusted processes.
    • Monitor for common malware techniques potentially enabled by hidden API calls (e.g., process injection via VirtualAlloc+WriteProcessMemory+CreateRemoteThread, suspicious network connections, attempts to disable security tools).
  4. Code Pattern Detection (YARA/Custom Rules): Develop detection rules (e.g., YARA) that identify specific code sequences observed during disassembly (see Analysis_Files/static_analysis/ folder), such as the API hashing/resolution routine pattern (e.g., involving calls to 0x402c7c preceded by specific push instructions). This can detect variants where file hashes may differ, but core logic remains.
  5. Network Traffic Analysis: Although no specific network IOCs were found statically, configure network monitoring (IDS/IPS, NetFlow) to detect anomalous outbound connections from endpoints, especially traffic patterns associated with known SpyEye C&C protocols or destinations (requires external threat intelligence). Consider analyzing the captured pcap file in the Analysis_Files/dynamic_after_analysis/ folder if C&C simulation was intended.
  6. User Awareness Training: Educate users about the risks of executing files from untrusted sources, phishing emails, and suspicious websites. Because the malware hides API calls, remediation should combine blocking known artifacts (hashes) with behavioural monitoring and potentially code-pattern detection to identify its execution, alongside standard network security and user training.

6. Conclusion & Indicators of Compromise (IOCs)

This analysis involved static examination (including PE parsing and disassembly) and limited dynamic testing (on Linux) of malware.exe, a suspected SpyEye variant, based on findings gathered from the analysis VM (raw data organized in repository folders: Analysis_Files/static_analysis/, Analysis_Files/dynamic_before_analysis/, Analysis_Files/dynamic_after_analysis/). Static methods successfully identified it as a 32-bit Windows PE file from 2010 and revealed potential capabilities and IOCs. Disassembly was crucial in uncovering dynamic API resolution as an obfuscation technique. The dynamic analysis limitations served as a practical lesson in environment setup. The combined findings provide a basis for detection and remediation strategies focused on both specific artifacts (hashes) and behavioural patterns. The key takeaway is that this sample exhibits characteristics of spyware, employing common obfuscation, and requires Windows-based dynamic analysis for full behavioural understanding.

Indicators of Compromise (IOCs):

  • File Hash (SHA256): f097ad77b99b3744994a646d6a3577cea2faa8b9e656fcccbbd73244e227c850
  • File Hash (MD5): 0f37839f48f7fc77e6d50e14657fb96e
  • Filename (Observed): malware.exe
  • Potential Resource/File Artifacts: Resource named CONFIG, string config.dat.
  • Code Patterns: API resolution routine (e.g., hash pushed, call to resolver near 0x402c7c, indirect call follows) identified in disassembly findings (see Analysis_Files/static_analysis/ folder).