MALWARE ANALYSIS: Malware analysis is the process of examining malicious software to understand its functionality, origin, and potential impact. This involves studying the malware's code, behavior, and structure to identify how it operates, how it spreads, and what kind of harm it can cause.
Malware analysis can be divided into two primary types:
Static Analysis:
Examining the malware without executing it. Analysts look at the code, file structure, and other characteristics to gather clues about its functionality. Tools like disassemblers, decompilers, and hex editors are often used in this process. Note : Basic static analysis does not require that the code is actually run. Instead, static analysis examines the file for signs of malicious intent. It can be useful to identify malicious infrastructure, libraries or packed files.
Dynamic Analysis:
Observing the malware's behavior in a controlled environment, like a virtual machine or sandbox, to see how it interacts with the system in real-time. This helps analysts understand the malware's actions, network connections, and any files or registry entries it modifies. Note: The challenge with dynamic analysis is that adversaries are smart , and they know sandboxes are out there, so they have become very good at detecting them. To deceive a sandbox, adversaries hide code inside them that may remain dormant until certain conditions are met. Only then does the code run.
**
. CASE SCENERIO:
**
An employee, Sarah, from the finance department of XYZ Corporation, received an email with the subject line "Quarterly Financial Review". Attached to the email was a file named "financials.xls". Believing the file contained important data, Sarah opened it. However, she noticed something unusual: the file briefly displayed blank cells before closing itself automatically.
Feeling suspicious, Sarah immediately contacted the IT team, who were tasked with investigating the file for potential malicious intent.
- STATIC ANALYSIS:
TridNet: is a tool used to identify file types based on their binary signatures, not just their file extensions.
TridNet identified the Excel .xml file as an executable, providing a key clue that the file was compressed using UPX.
- HXD Analysis: Hex Editor Allows you to view the raw binary data of a file, grouped into bytes and displayed in hexadecimal format. This is useful for seeing exactly what a file contains.
HxD: Opening the file in HxD, I observed a file signature starting with 4D 5A 90 00, which is commonly known as the "MZ" signature. This signature is a strong indicator that the file is a Windows executable (EXE) rather than a PDF. To confirm this, I’ll use the website file signature to look up the hex pattern and verify its classification.
Hashcalc: Hash values play a critical role in investigations because they provide a unique identifier for files, making it easy to track and verify them without directly interacting with potentially dangerous contents.
Time to get the hash and upload it, but I learned some organizations use their own tools like VirusTotal so threat actors don’t know they’ve been discovered. This is new to me.
I’ll scan the MD5 hash on VirusTotal since I don’t have access to private scanning tools, lol.
I can see 56 vendors have already flagged this file as malicious, so it’s clearly a well-known malicious document
- Header Analysis:
CFF Explorer: CFF Explorer is a versatile tool designed for examining and editing Portable Executable (PE) files, the standard format for executables in Windows. It offers detailed insights into various aspects of PE files, including headers, sections, imports, exports, and resources.
Key Observations: 2.file type : 32-bit Portable Executable (PE)
file info: UPX 2.90 [LZMA] (Delphi stub) -> Markus Oberhumer, Laszlo Molnar ...
- PE Size : The file size is small (42.50 KB), which is typical of packed files.
OPTIONAL HEADER ANALYSIS:
This confirms that it’s a packed file. UPX is a packer used to compress files, making them harder to analyze.
- Images Based :
The Image Base is a critical field in the Optional Header of a PE file. It specifies the preferred virtual memory address where the operating system should load the file.
Address of Entry Point: The Address of Entry Point is the address where execution starts. It is given as an RVA (Relative Virtual Address).
Section Headers Analysis: It obvious this file has been packed so i could unpacked it here using CFF Explorer UPS Utility.
UFX UTILITY:
We could unpack it here, but I’ll be using the command line to unpack it into a new .exe file.
UPX Unpacker :
Compression Ratio:
75.89%, meaning the packed file is much smaller than the unpacked one.
Packers compress files, obfuscate their contents, and can hide malicious code to evade detection and analysis.
Analysis on the unpacked file:
In CFF Explorer, adding the Image Base and the Address of Entry Point (EntryPoint RVA) gives you the absolute memory address where the program's execution begins once loaded into memory. This helps identify the starting point of the executable code.
- STRING ANALYSIS: BinText is a lightweight utility designed to extract text strings from binary files. It is particularly valuable for reverse engineering and malware analysis, as it enables analysts to view ASCII and Unicode strings embedded within executables and other binary formats.
The string includes a scareware message warning the user that their computer is infected, likely designed to pop up after the executable has completed its malicious actions.
I see an IP address and URL in the string. The malware is likely set to reach out to this address after execution, probably connecting to a C2 server for further instructions or data exfiltration.
In this section, I can see a registry path that will be modified to download an "install.bat" file: Software\Windows\CurrentVersion\Run\Install.dat. This registry key is commonly used to automatically launch programs when Windows starts. By modifying this key, the malware ensures that the "install.bat" file will run every time the system boots up. This technique is often used to hide malicious files and ensure persistence on the infected system.
API CALLS ON WINDOWS:
API Categories:
Window Management (USER32.dll): Functions like ShowWindow, FindWindowA, and SendMessageA manage GUI elements. Techniques like T1055 | Process Injection highlight potential abuse for malicious purposes (e.g., injecting code into another process via window handles).
Registry Operations (ADVAPI32.dll): • Functions like RegSetValueExA, RegDeleteKeyA, and RegQueryValueEx A manipulate the Windows Registry. • Associated MITRE ATT&CK techniques (T1112, T1485, T1012) indicate potential use for modifying, deleting, or querying registry values.
File and Directory Operations (KERNEL32.dll):
• Includes functions like CreateFileA, DeleteFileA, and CopyFileA. • Techniques like T1485 (data destruction) and T1105 (remote file copy) suggest possible malicious activities like data deletion or exfiltration.
Conclusion: File Type & Packing: The file is a Windows executable (PE), packed with UPX to evade detection and obfuscate its true intent.
- Persistence Mechanism:
It modifies the registry (Software\Windows\CurrentVersion\Run\Install.dat) to ensure the malicious "install.bat" runs on system startup, ensuring persistence.
- C2 Communication:
The file includes an IP address and URL, suggesting it communicates with a Command and Control (C2) server for further instructions or data exfiltration.
- Known Malware:
VirusTotal flags the file as malicious, confirming it's a recognized threat. The presence of scareware messages indicates deceptive behavior.
- Malicious Behavior:
API calls show the malware manipulates system files, modifies the registry, and may inject code or exfiltrate data, aligning with known attack techniques.
DYNAMIC ANALYSIS: Observing the malware’s behavior in a controlled environment, like a virtual machine or sandbox, to see how it interacts with the system in real-time. Tools use for this section are FAKENET: PROCMON PROC EXPLOERER PROCESS HACKER WIRESHARK REGSHOT PROCDOT
I began dynamic analysis by launching the malware in a controlled environment, ensuring all my monitoring tools were prepared to capture the events and activities triggered by the malware during execution.
Observations and Interpretations
- Registry Changes
o Observation: 4 keys deleted, 68 added, 67 values added, 45 modified. o Interpretation: Significant registry modifications suggest possible system changes or malicious activity.
- File Operations
o Observation: 3 files added, 12 modified, 5 folders added, no deletions. o Interpretation: New files/folders and modifications may indicate program installation or malicious behavior.
- Access to System Directories
o Observation: File access (ReadFile, CreateFile) in C:\Windows\Syst.... o Interpretation: Access to critical directories could be part of legitimate operations or malicious intent.
- Total Changes
o Observation: 205 total changes logged. o Interpretation: High volume of changes points to significant system activity, potentially suspicious.
- Procmon Analysis :
While using Process Tree in Procmon, I couldn't find any significant activity related to the running executable, though I did observe that it launched and quickly exited. It’s possible that the malware self-terminated after execution. To gain more insight, I’ll move on to using Process Explorer to further investigate the process and potentially uncover additional details.
- PRCOESS EXPLORER:
I couldn't locate the process in Process Explorer, even though Process Monitor indicates that it has a parent ID of 3604, which corresponds to explorer.exe. It seems that the process may have terminated itself, as it doesn’t appear under explorer.exe in Process Explorer.
As a next step, I will analyze the Regshot logs to determine which registry values were modified and which files were added. This will help me understand the actions of the process — whether it replicated itself or installed another executable from the C2 server
Regshot Analysis:
After being unable to find any clear leads on what the malicious program did, I decided to check the registry changes recorded in the Regshot logs. This will help me identify any values added by the portable executable. By examining these changes, I hope to gain insight into the program's behavior, such as whether it is attempting to establish persistence by hiding in Software\Windows\CurrentVersion\Run\ that I saw earlier in the string analysis
Upon analyzing the registry values in the Regshot output, I discovered that the malicious program created a file called update.exe under the C:\Windows folder. This is likely a self-replication attempt to maintain persistence, especially since the process seems to have terminated itself. To confirm whether this is a new file or a replication of the original executable, I will calculate the MD5 hash for the update.exe file.
After calculating the MD5 hash, I observed that it matches the hash of the unpacked version of the executable. This indicates that the file is a replica of itself, likely created to maintain persistence and ensure it launches at system startup.
- PROCDOT ANALYSIS:
- Observations:
Malware Process: financials.exe (PID: 1660) is the originating process.
- Registry Persistence:
Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: Windows update loader → Points to C:\Windows\xpupdate.exe
- File Creation:
C:\Windows\xpupdate.exe C:\Users\Pawn\AppData\Roaming\Install.dat
Thread Spawning:
PIDs 1768 and 3676. Behavior: The process terminates itself for anti-analysis, which is why it doesn't appear in Process Explorer.
I can confirm that it created update.exe first by using the Process monitor in ProcDot feature. This allowed us to track the process from start to finish, revealing its creation of update.exe.
After creating the update.exe file, the malware modifies the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key (value: Windows update loader) to enable auto-start. It then creates the install.dat file.
After creating the install.dat file it sent an http request to this ip address that was found in the string on tcp port 80
The financial.exe received a response from the ip address.
It then write data into install.dat
It then modify the autostart registry key
It then kill own process
- file Aanalysis:
The .dat file that was created is a fakenet page, guess it tried to reach out to the C2 Server and FakeNet redirected the traffic.
- Ip address Analysis
- Network Analysis:
I couldn't find any HTTP or DNS packets that point to the domain found in the string analysis.
- Conclusion:
- • AV Detection:
o The malware sample was detected by various antivirus scanners, including machine learning-based detection for both the submitted sample and dropped file. Persistence and Installation Behavior: • The malware drops executables in the C:\Windows directory and launches them, indicating typical installation behavior aimed at system compromise. • The malware also creates an autostart registry key, pointing to a binary in C:\Windows, ensuring it can survive reboots and maintain persistence.
- Malware Evasion:
• During execution, the malware exhibits stalling behavior and ends with an API Sleep call, a typical evasion tactic designed to delay or hide malicious activities from detection.
- C2 Server Communication:
• The malware attempts to connect to a C2 server located in Canada, as indicated by network traffic analysis. This connection was likely intended for command and control, with the malware potentially awaiting further instructions or data exfiltration.