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: 1. 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. 2. 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 : A staff member receives an email with what looks like a simple budget report attachment. It’s from a trusted contact, so they open it without hesitation. But once the file is opened, it disappears from the screen. At first, it seems like a glitch, but in the background, the file is silently executing malware.

The malware quickly begins to compromise the system and spreads across the network. The IT department is called in to investigate.

As the firm's cybersecurity analyst, you're tasked with investigating this suspicious file. Your first step will be to inspect the PDF document to determine if it contains malicious code or exploits, which could have caused the unexpected behavior on the accountant's laptop. You’ll likely run tests in a controlled environment, examining the file properties, looking for any embedded scripts, and scanning for possible malware, especially since phishing or malware attacks targeting financial departments are common.

STATIC MALWARE ANALYSIS:

To begin my investigation, I set up a FLARE VM, an isolated environment specifically designed for analyzing suspicious files. FLARE VM serves as a secure sandbox for malware analysis, allowing for a thorough examination without risking the integrity of other systems. This setup is crucial, as it enables me to safely open, inspect, and dissect the potentially malicious PDF file in a controlled environment. By using FLARE VM, I can analyze the file’s behavior, identify any embedded scripts, and determine if it contains malicious code that could have caused the system disruptions reported by the financial department. This approach is a best practice in cybersecurity for examining suspicious files, particularly in cases where phishing or malware may be involved.

Tools use for needed for this project include:

Analysis: File-Type Analysis : I will start my analysis by performing a file type analysis to confirm the true nature of the PDF file. This step is essential to verify if the file is genuinely a PDF or if it has been disguised to appear as one. By identifying the actual file type, I can ensure that I’m using the right tools and precautions, minimizing the risk of accidentally executing any hidden malicious content. This initial analysis will also guide me in selecting the appropriate techniques for a deeper inspection of the file.

Although the file appears with an Adobe icon, suggesting it is a PDF, this visual cue alone is not sufficient to confirm the file type. To verify its true nature, I will conduct a deeper analysis using TrIDNet and a hex editor. TriDNet: Helps identify the file type based on its binary signature, preventing you from relying solely on file extensions or misleading icons. 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. ![TriDNet] TriDNet Identify the file as Win32 executable file with 44.6% so this already shows us that it an executive file and not a pdf like it proclaim to be.

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.

The "MZ" header, named after Mark Zbikowski, one of the original MS-DOS developers, marks the beginning of DOS executables and 32-bit Windows executables. Identifying this header is crucial in distinguishing potentially malicious executables that may have been disguised with a misleading icon or extension.

After confirming the file type, I’ll proceed by obtaining the hash value of the file to determine if it is a known executable. Using HashMyFiles, I’ll generate the file's hash values, such as MD5 or SHA-256. These hashes will allow me to cross-reference the file against known malware databases to check if it matches any previously identified malicious executables. This step is essential for quickly assessing the threat level and determining if the file has been flagged as malware in existing databases.

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. By generating the hash (e.g., MD5, SHA-1, SHA-256) of a suspicious file, we can compare it to known hashes in malware databases, helping to quickly determine if the file has been previously flagged as malicious. This is especially useful in cybersecurity investigations, as it allows analysts to identify and assess threats efficiently. One of the most effective ways to check a file's hash is through VirusTotal, a platform that checks files against dozens of antivirus engines. By submitting the hash to VirusTotal, investigators can quickly see if the file matches any previously identified malware, view detailed reports, and gain insights into the file's behavior from multiple sources. This saves time and reduces the risk of accidentally launching malicious code, as the hash can be analyzed independently of the actual file content.

MD5: d7cc6c987c68a88defdab3a59070777e

From checking on VirusTotal, we observed that the hash has been flagged by multiple antivirus engines, indicating that this file is likely malicious. This finding suggests that the file matches known malware signatures, and its behavior or contents have previously been identified as harmful by various security vendors. Consequently, this confirmation means we should treat the file as a verified threat, and further steps should be taken to ensure that it is contained, investigated, and that any potential impact on the system or network is mitigated.

Header Analysis PE Studio :

1 Entropy Analysis: • Entropy Value: The entropy is around 5.4. • Interpretation: Entropy measures the randomness within the file's content, typically on a scale from 0 to 8. High entropy (close to 8) often indicates the presence of encrypted or compressed data, commonly used in malware to obfuscate its contents. In this case, an entropy of 5.4 suggests some level of randomness, but not as high as usually seen with packed or fully encrypted malware. It could mean that the file contains obfuscated or slightly compressed data but is not entirely packed. 2. Signature: • Signature: Marked as "n/a" (not available). • Interpretation: This indicates that the file does not have a digital signature, which is common for malware. Legitimate software usually comes with a signature from the developer, helping to verify its source and integrity. Lack of a signature is often a red flag, especially if the file is from an unknown or untrusted source. 3. File Details: • Timestamp: The compiler timestamp is from October 14, 1998. While this could be genuine, it could also be a forged timestamp to evade detection or appear outdated. • File Type: The executable is a 32-bit GUI application, suggesting it might be designed to interact with users through a graphical interface, possibly to trick them into executing commands or installing additional payloads.

Characteristics (0x030F) • Flags: o 0x0100 (32-bit words support): Indicates the file is intended for 32-bit architecture. o 0x0002 (Executable file): Confirms that this file is executable. o 0x0200 (Debug stripped): Debugging information has been removed from the file, which is a common tactic for malware, making analysis more difficult. o 0x0004 (Line numbers stripped): Line number information is also removed. o 0x0008 (Local symbols stripped): Local symbols are stripped, which again hinders reverse engineering. o Interpretation: These stripped characteristics imply that this file was likely designed to prevent detailed analysis, a common feature in malware. 2. General Information • Compiler-Stamp: The timestamp here is set to October 14, 1998, as seen in the previous image. This timestamp could be legitimate, but it might also be forged to evade detection or mislead investigators into thinking this file is old and, therefore, possibly safe. • Size of Optional Header (0x00E0): This size (224 bytes) indicates a fairly standard PE header for a 32-bit executable. • Signature: The file's PE (Portable Executable) signature, PE00, identifies it as a PE file, a common format for executables in Windows. • Machine (0x014C): This corresponds to Intel 386 architecture, indicating it's designed to run on 32-bit x86 machines. • Sections Count: The file has 9 sections, which is on the high end for typical executables. Malware often adds extra sections for payloads, obfuscation, or other purposes.

Based on the PE Studio analysis, here is an explanation of each indicator and what it means in the context of malware analysis: VirusTotal Score (62/75): • This score shows that 62 out of 75 antivirus engines flagged this file as potentially malicious. A high VirusTotal score strongly indicates that the file contains malware or malicious elements. The VirusTotal score is an essential indicator of how many security vendors recognize the file as harmful. Suspicious Groups > API: • This entry lists the types of APIs (Application Programming Interfaces) that the file uses. APIs like security, registry, data-exchange, synchronization, and execution are commonly associated with actions that malware might perform, such as accessing system resources, modifying registry keys, or executing commands. The presence of these APIs could indicate potential malicious behavior. Thread-Local Storage > Callbacks (3): • This indicates that the file contains three thread-local storage (TLS) callbacks. TLS callbacks are often used by malware to execute code before the main entry point of the application, which can help it avoid detection by some analysis tools. MITRE Technique: • PE Studio associates this file with specific MITRE ATT&CK techniques, such as T1134, T1112, T1485, etc. Each code corresponds to a recognized technique that threat actors use in attacks. o For example:  T1134: Access Token Manipulation.  T1112: Modify Registry.  T1485: Data Destruction. File > Compiler > Stamp: • This field shows the timestamp of the file, set to "Wed Oct 14 08:31:48 1998." This date may be suspiciously old or forged, as malware authors sometimes use fake timestamps to mislead investigators or make the file appear benign.

Libraries (group >network> ) Analysis :

WININET.DLL Analysis The presence of WININET.DLL in this executable suggests potential internet communication, which is often flagged in malware due to its capability to interact with FTP and HTTP protocols. This API allows the program to perform tasks such as downloading additional payloads, exfiltrating data, or communicating with command-and-control (C2) servers. These behaviors are commonly associated with malware, indicating possible intent to interact with external servers and potentially compromise system security.

Import Function Analysis : The executable’s import section includes flagged functions indicating possible malicious behavior: • Synchronization: WaitForSingleObject, WaitForMultipleObjects (KERNEL32.dll) help control operation timing. • Privilege Manipulation: AdjustTokenPrivileges, LookupPrivilegeValueA (ADVAPI32.dll) can elevate privileges (T1134). • Registry Access: RegCreateKeyExA, RegSetValueExA (ADVAPI32.dll) allow registry modifications, supporting persistence and data destruction (T1112, T1485). • Network Communication: InternetOpenA, InternetOpenUrlA (WININET.DLL) enable internet access, suggesting possible data exfiltration. • File Manipulation: CopyFileA, DeleteFileA (KERNEL32.dll) allow file management, which could aid in data destruction (T1485). • Memory Manipulation: VirtualProtect, HeapAlloc (KERNEL32.dll) are often used in process injection (T1055). • Process Execution: CreateProcessA, CreateThread (KERNEL32.dll) enable process spawning for added execution paths (T1106). These imports suggest capabilities for persistence, privilege escalation, communication, and data manipulation, often seen in malware.

STRING ANALYSIS :

Key Observations 1. Registry Manipulation: o Functions like RegSetValue, RegCreateKeyEx, RegDeleteValue, RegOpenKeyEx, and RegQueryValueEx indicate that this executable interacts with the Windows Registry. These actions are associated with MITRE ATT&CK techniques like T1112 (Modify Registry) and T1485 (Data Destruction). o These functions suggest potential registry modifications, deletions, or queries, often used for persistence, configuration, or covering traces. 2. File Operations: o Functions such as CreateFile, DeleteFile, CopyFile, MoveFileEx, ReadFile, WriteFile, and SetFileAttributes indicate that the malware has capabilities related to file handling. o These could be tied to T1105 (Remote File Copy), T1083 (File and Directory Discovery), and T1485 (Data Destruction), showing it can copy, move, delete, and modify files or directories. These abilities could be used for exfiltration, destruction, or installation of additional payloads. 3. Process and Memory Manipulation: o Functions like CreateProcess, CreateThread, OpenProcess, SuspendThread, ResumeThread, SetThreadContext, and TerminateProcess suggest the malware can control processes and manipulate threads, hinting at T1055 (Process Injection) and T1057 (Process Discovery). o Memory manipulation functions like VirtualProtect, HeapAlloc, GlobalAlloc, GlobalLock, GlobalUnlock indicate potential memory injections or allocations for malicious code execution. 4. Network Communication: o Network-related functions such as connect, send, gethostbyname, InternetOpen, InternetOpenUrl, InternetReadFile, and closesocket imply that the malware has capabilities for network communication. o These functions indicate it may be used for Command and Control (C2), allowing it to connect to remote servers, potentially for data exfiltration or receiving commands. 5. Synchronization and Critical Sections: o Functions like CreateEvent, CreateMutex, CreateSemaphore, DeleteCriticalSection, EnterCriticalSection, LeaveCriticalSection, and WaitForSingleObject suggest that the malware uses synchronization mechanisms. o This could mean it is designed to work in a multi-threaded environment, manage concurrency, or use mutexes to prevent multiple instances from running. 6. Window Management: o Functions like CreateWindowEx, DefWindowProc, FindWindow, ShowWindow, RegisterWindowMessage, and TranslateMessage indicate windowing capabilities, suggesting it might try to create fake windows or manage its own GUI. o Such functions are often used to mimic legitimate applications or trick users with fake interfaces. 7. Reconnaissance and System Information: o Functions like GetSystemInfo, GetCurrentProcessId, GetThreadContext, GetTickCount, and GetVersionEx are often used for reconnaissance. o This aligns with T1012 (Query Registry) and T1057 (Process Discovery), suggesting the malware might gather system information, including hardware and OS details. 8. Security and Access Token Manipulation: o Functions like AdjustTokenPrivileges, LookupPrivilegeValue, OpenProcessToken, and SeDebugPrivilege hint at T1134 (Access Token Manipulation). o These capabilities allow the malware to elevate its privileges, giving it more access to the system's protected resources and potentially bypassing certain security restrictions. 9. Strings and ASCII Analysis: o The frequent references to ASCII strings, often accompanied by function imports in the .idata and .rdata sections, suggest a lot of text processing or embedded strings. o This could mean the malware has hard-coded URLs, commands, or data it needs to operate, potentially related to C2 communication or configuration settings.

Potential Behavioral Summary The malware seems designed for multi-functional capabilities, with registry manipulation, file management, process injection, and network communication. It appears capable of modifying critical settings, performing process and memory manipulations, executing commands remotely, and handling synchronization, suggesting a highly complex design. Its functionalities indicate it could be used for data theft, persistence, privilege escalation, C2 communication, and system manipulation. Each of these elements aligns with typical behaviors seen in advanced malware, particularly those focused on espionage, data exfiltration, or maintaining a hidden presence on the system.

Conclusion of Static Analysis With just a few tools—TrIDNet, PE Studio, and HashMyFiles—I gathered significant information: • The file type is an executable, despite the deceptive icon. • The file exhibits numerous Indicators of Compromise, like blacklisted APIs, encoded strings, and suspicious behaviors. • The cryptographic hash matched a known malware, confirming the analysis.

DYNAMIC ANALYSIS:

In this phase, we will execute the malware to observe and analyze its behavior in a controlled environment. This step requires extra caution, as running the malware can trigger harmful actions if not properly contained. By interacting with the malware, we aim to gain insights into its operations, network activity, registry changes, and process interactions. The primary tools needed for this phase are: • FakeNet: It will monitor and intercept any Internet traffic from the malware. • RegShot: Takes snapshots of the Windows registry before and after running the malware, helping to identify any registry modifications. • ProcMon: Monitors and logs real-time system activity, such as file, registry, and process operations, to reveal the malware's internal actions. This setup allows for a thorough investigation of the malware’s behavior and potential impact. I initiated ProcMon, cleared the logs to ensure a fresh start, and then paused the capture. Due to the extensive data ProcMon collects, it's important to be selective to avoid an overload of unnecessary events. This will minimizes noise and helps us capture only relevant system interactions triggered by the malware.

FakeNet Analysis FakeNet was launched to monitor potential HTTP requests or other network traffic generated by the malware. This setup allows us to intercept and analyze any attempts by the malware to communicate with a command-and-control (C2) server. Earlier, in our PE Studio analysis, we identified that the malware imports wininet.dll, a library that enables HTTP and FTP requests. Monitoring network activity here is essential to understand any external communications the malware might attempt.

Regshot : RegShot was used to capture an initial snapshot of the system registry before executing the malware, with the snapshot saved in the designated "reg-shot" folder. After launching the malware, a second snapshot will be taken and compared with the first to identify any registry changes made by the malware during execution. This comparison helps reveal any alterations to the system settings or configurations that could indicate malicious behavior.

RegShot Comparative Analysis Results

Value added Section:

In this section we could see the value added ctfmon.exe which is obvious the budget-report imported or renamed itself to ctfmon .exe

Procmon Analysis: Using ProcMon's filter feature, I'll focus on tracking key activities to capture the malware's specific behaviors. I'll apply filters based on crucial operations, including: • RegSetValue: Observes registry changes, which could signal persistence mechanisms or system configuration modifications. • CreateFile: Tracks file creation, often used by malware to store payloads or log data. • SetDispositionInformationFile (with Disposition set to "F"): Detects attempts to rename or delete files, indicating potential file obfuscation or cleanup by the malware. • Process Create: Monitors new process executions, which could reveal secondary processes or additional malware payloads. • UDP/TCP: Observes network connections, essential for detecting communication with a Command and Control (C2) server. These filters will allow focused monitoring of the malware's activities, enabling identification of critical actions without excessive background noise.

During the analysis, I reviewed the process tree and observed that the malware (budget-report.exe) had spawned other processes, including cmd.exe. This command-line activity executed instructions within the Temp folder, a commonly targeted location for malicious files. The Temp folder is often used by malware because it allows temporary file creation and execution without requiring elevated permissions. By writing or executing files here, malware can remain inconspicuous, as the folder is designed to store temporary data. Attackers often use this location to drop additional payloads, scripts, or command sequences, enabling persistence or further actions while evading some detection tools like Process Hacker, which may not always reveal all underlying processes.

We could see the process parent-child relationship,

We noticed the command was launch from the Tempt folder and the randomly generated .bat file let us know the malware dropped another payload in the temp folder, likely a copy of itself to gain persistence and avoid detection.

Further in the analysis, we observed that cmd.exe, initiated by budget-report.exe, also called conhost.exe. This executable, located in Windows\System32, ran with the specific command conhost.exe 0xffffffff -ForceV1.

During the review of the Temp folder, the .bat file was missing, which raised suspicions about persistence mechanisms.

AFTER

PROCDOT ANALYSIS :

Observed Behavior Registry Modifications for Persistence: The malware makes several edits to the Windows Registry, specifically in the HKCU\Software\Microsoft\Windows\CurrentVersion and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce keys. These edits are common techniques used by malware to achieve persistence, ensuring the malicious payload is executed upon system startup.

RunOnce Key: Entries such as HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\112648430 are configured to execute the malware each time the system reboots, effectively re-launching budget-report.exe without user intervention.

Process Masquerading as ctfmon.exe: Interestingly, budget-report.exe renames itself as ctfmon.exe and relocates to C:\Users\Pawn\AppData\Roaming\112648430\ctfmon.exe. The real ctfmon.exe is a legitimate Windows process associated with the language bar and is typically located in the System32 directory. By mimicking this legitimate process, the malware attempts to blend in with standard system files, reducing the likelihood of detection.

Network Connections: The malware also initiates outbound connections to an external IP (192.0.2.123), possibly for command-and-control (C2) purposes. Several TCP connections are observed, indicating that budget-report.exe is communicating with a remote server, potentially to receive commands or exfiltrate data.

Additional File Modifications: System log files such as SOFTWARE.LOG2 and tuser.dat.LOG2 appear to have been modified, suggesting that the malware may be attempting to cover its tracks or log its own activities.

The file ctfmon.exe now has the same MD5 hash as budget-report.exe, indicating that it has replicated itself.

Process Explorere Analysis:

In Process Explorer, I can see all the .dll files being used by the budget-report.exe process. However, the name ctfmon.exe stood out. After checking its properties, I discovered suspicious strings in memory associated with it.

I searched for the name "ctfmon" and came across a list of strings. When I first ran the malware, it used the name csrss, but now it is using ctfmon. It seems the malware dynamically selects its name from a list of these possible strings.

QUOTE: "The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown"

I could see some encoded url, shell_trayWnd and firewall policy in the strings.

System Enumeration and Persistence:

References to **Shell_TrayWnd, regedit.exe, taskmgr.exe, cmd.exe, msconfig.exe, and autoruns.exe:** The malware might be monitoring or trying to disable these programs to prevent detection or removal. Windows Registry entries for firewall policies and startup items: The malware could be adding itself to firewall exceptions or modifying Registry values to ensure it launches on system boot or maintains access.

Remote Communication:

Strings such as http://, https://, and %S@%S:%i hint at the possibility of the malware communicating with a remote command and control (C2) server, likely for receiving commands or sending stolen data. Could receive commands remotely from a C2 server, enabling it to perform actions like downloading additional files, stealing data, or launching further attacks.

Network Analysis:

My laptop try to connect with the C2 Server

The communication attempts from 192.168.56.101 to 192.0.2.123 are suspicious, especially since 192.0.2.123 is part of a reserved IP block typically not used in legitimate network traffic. This suggests that the malware is programmed to reach out to this IP, potentially as a placeholder for a C2 server or as part of a test configuration in the malware's code. Malware wasnt able to communicate with the C2 Server because FakeNet-NG blocked the http POST

Report Preparation & Indicators of Compromise (IoCs)

The budget-report file with MD5 hash d7cc6c987c68a88defdab3a59070777e has been flagged as malicious by multiple antivirus engines. Static and dynamic analysis reveal significant indicators of malware behavior, including persistence mechanisms, privilege escalation, network communication, and potential data exfiltration.

Key Findings: VirusTotal Score: 62/75, with multiple antivirus engines marking it as malicious. Entropy: 5.4, indicating moderate obfuscation or compression. Lack of Digital Signature: No valid signature, a common trait for malware. File Characteristics: Executable (32-bit), with 9 sections (indicating possible payloads or obfuscation). Indicators of Compromise (IoCs): Registry Modifications:

Persistence via RunOnce and Run registry keys. HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\112648430 used to re-execute malware on reboot. Suspicious Behavior:

Masquerades as ctfmon.exe in C:\Users\Pawn\AppData\Roaming\112648430. Spawns cmd.exe and conhost.exe processes from the Temp folder. Network Activity:

Attempts to connect to 192.0.2.123, likely a Command and Control (C2) server. Communication was blocked by FakeNet-NG during analysis.

API Usage:

Registry Access: RegCreateKeyExA, RegSetValueExA (Persistence). Network Communication: InternetOpenA, InternetOpenUrlA (C2). Privilege Escalation: AdjustTokenPrivileges, LookupPrivilegeValueA.

File Operations:

File Deletion: Uses DeleteFileA and CopyFileA to manipulate files, potentially for data destruction or exfiltration.

---