lab1

Lab 1-1

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

Both files matched existing AV signatures.

When were these files compiled?

For this lab, and for the rest of the book, I will be using Manalyze for all analysis since most of the tools referenced in this chapter are now outdated.

Lab01-01 has a compilation timestamp of 2010-12-19 16:16:19 UTC, and Lab01-01.dll has a compilation timestamp of 2010-12-19 16:16:38 UTC; both were compiled approximately at the same time.

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

The initial scan output shows no evidence of a packed executable. To confirm this further, we examine the imports table using the -dimports flag.

From the imports table, it’s clear that this is not a packed executable. If the file were packed, we would not see the usual C runtime functions, such as malloc or _initterm.

One additional indicator is entropy, which measures how random the data in a file (or in each section of a file) is.

Across all sections, the randomness never reached suspiciously high values that would indicate obfuscation, a common trait of packed binaries. Packed or encrypted code typically appears as a blob of random-looking bytes, resulting in high entropy.

We also note that the VirtualSize values are close to the SizeOfRawData for all sections, except .rdata, which is normal for compiled, unpacked binaries. On disk, sections are aligned to the file alignment, usually 0x200 (512 bytes) or 0x1000 (4096 bytes). Even if .rdata only uses 690 bytes, Windows stores it in a 4096-byte chunk to satisfy alignment requirements. The extra bytes are simply padding, often zeros, to meet the alignment rules.

The same analysis applies to the DLL, and we can similarly conclude that it is also unpacked.

Do any imports hint at what this malware does? If so, which imports are they?

The import table of the EXE indicates that it is primarily focused on file operations and directory traversal. APIs such as CreateFileA, CopyFileA, FindFirstFileA, and FindNextFileA show that the executable interacts heavily with the filesystem, opening, copying, and enumerating files. The presence of more advanced APIs like CreateFileMappingA and MapViewOfFile suggests that it might also manipulate files directly in memory, a technique often used for efficient in‑place modification or scanning of file contents.

The DLL, however, shows a very different behavioral profile. Its imports clearly indicate network communication capabilities, specifically through Winsock APIs imported from WS2_32.dll. Functions like socket, connect, send, recv, inet_addr, and htons show that the DLL establishes network connections, sends and receives data, and communicates with remote hosts. This strongly suggests that the DLL serves as the networking component of the malware. Additionally, the presence of CreateProcessA and mutex-related functions (CreateMutexA, OpenMutexA) indicates that the DLL may create child processes or use mutexes to enforce single-instance execution, common malware tactics to avoid multiple infections or to manage runtime synchronization.

When viewing the EXE and DLL together, a very clear division of labor appears. The EXE acts as the loader or controller, performing local file operations, scanning, or preparing data. The DLL handles network operations, providing communication capabilities such as connecting to a command-and-control server, sending stolen data, or receiving further instructions. This separation of functionality is a common technique in malware design, where one component focuses on local actions while another handles external communication.

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

Based on the EXE’s file-manipulation imports, you should look for any unusual files created, modified, or copied by the malware. This might include dropped executables, temporary files, or modified files in directories that the malware scans. The use of memory‑mapped file functions suggests that it may modify files directly, so checking file integrity (hash mismatches or unexpected changes) would also be relevant.

It would also be important to examine C:\Windows\System32\kerne132.dll, since the strings output from the executable references this path. The filename closely imitates kernel32.dll, suggesting the malware may be attempting to disguise itself or perform DLL hijacking by masquerading as a legitimate system library.

Additionally, the DLL creates and uses mutexes, so inspecting the system for unusual or unfamiliar mutex names could help identify an active infection. The presence of CreateProcessA suggests that it may launch other executables, so reviewing process creation logs and looking for unexpected child processes would provide more indicators.

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

The DLL’s imports point strongly to network activity, so you should also check for outbound connections to suspicious IP addresses or ports. Winsock APIs indicate that the malware communicates over the network, possibly with a command‑and‑control server, so examining firewall logs, DNS cache, and connection history would be valuable.

Running strings on the DLL reveals the IP address 127.26.152.13. In a real intrusion scenario, this would likely be a legitimate, routable IP pointing to the attacker’s command‑and‑control server, from which they could issue commands or exfiltrate data.

What would you guess is the purpose of these files?

The purpose of these files appears to be multi‑stage malware consisting of a dropper and a network-enabled payload. The EXE seems responsible for scanning directories and copying or dropping files, including a suspicious fake system DLL (kerne132.dll) that suggests DLL hijacking or persistence.

Lab 1-2

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

The exe match multiple existing AV definitions and is flagged by 59 out of 72 AVs.

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.

This executable is almost certainly packed since its import table is unusually small. To further confirm this, we inspect its sections:

As expected, this binary is packed. The section names are atypical, and the second section shows an entropy of 7.06, indicating high randomness and obfuscation. The packer appears to be UPX, as suggested by the section names.

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

Once unpacked, we examine the imports table of the original binary:

Several of the imported functions give very clear hints about the program’s intended behavior. The most revealing imports come from ADVAPI32.dll: CreateServiceA, OpenSCManagerA, and StartServiceCtrlDispatcherA. These APIs are typically only used by programs designed to install or manage Windows services. Their presence strongly suggests that the program attempts to install itself as a persistent Windows service, likely to ensure it runs automatically at system startup and operates with elevated privileges. This is a common persistence technique employed by malware.

The imports from WININET.dll (InternetOpenA and InternetOpenUrlA) are equally significant. WinINet is a high-level API used for HTTP and HTTPS communication. When malware imports these functions, it usually indicates that the program needs to communicate with an external server, typically a command-and-control (C2) server. Through these functions, the malware can download additional payloads, receive instructions, or exfiltrate data over the network. Their presence almost always points to remote communication capabilities.

The imports from KERNEL32.dll provide additional context. Functions like CreateThread indicate that the malware is multi-threaded, allowing it to perform background tasks independently, such as networking or persistence checks. CreateMutexA and OpenMutexA are commonly used to ensure only one instance of the malware runs at a time, preventing duplicates or accidental re-infection. Functions such as CreateWaitableTimerA, SetWaitableTimer, and WaitForSingleObject suggest that the program may delay execution, schedule repeated actions, or synchronize internal operations, which is consistent with background service-like malware behavior.

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

The malware creates a persistent service that runs at startup, allowing it to maintain control over the system. Host-based indicators include unusual services with names found in the strings output, such as MalService, or examining service binary paths to identify executables stored in non-standard locations such as %APPDATA%, %TEMP%, or other uncommon directories.

Network-based indicators are also evident from the imported WinINet functions InternetOpenA and InternetOpenUrlA, suggesting the malware communicates over HTTP. The strings reveal a hardcoded URL, http://www.malwareanalysisbook.com, which in a real scenario would represent a command-and-control server. Monitoring for outbound connections to unusual URLs or IP addresses could help detect the malware. Additionally, the string Internet Explorer 8.0 indicates that the malware may spoof an old browser user-agent in its network requests, which can also be used as a detection signal by network defenders.

Lab 1-3

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

The exe matches multiple existing AV definitions and is flagged by 64 out of 72 AVs.

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.

This binary is clearly packed, as indicated by the warning message from Manalyze. The compilation date is also suspicious, corresponding to the epoch (0), which is often a sign of tampering or packing. Attempting to view the import table results in an error, and the section analysis shows that most sections contain meaningless or junk values, further confirming that the file is obfuscated.

Lab 1-4

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

The exe matches multiple existing AV definitions and is flagged by 64 out of 72 AVs.

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.

Examining the imports table, we can deduce that this program isn’t packed since the imports include some of the typical C runtime functions like _exit and _snprintf

When was this program compiled?

First thing we notice when we run the manalyze command is the compilation time, 2019-Aug-30. As of the time of writing, this date might seem logical. But then let’s remember that the github repo for the book wasn’t update in 8 years, and virus total scan indicates that time this malware was First Seen In The Wild is 2011-07-05 18:16:16 UTC. So we can’t deduce its compilation time.

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

Several of these imports give strong hints about what this program is designed to do. The imports from KERNEL32.dll reveal that the malware is performing both file and process manipulation. Functions like CreateFileA, WriteFile, MoveFileA, GetTempPathA, and GetWindowsDirectoryA indicate that the program reads, writes, and moves files across the system, possibly to copy itself or drop additional payloads. The presence of WinExec, CreateRemoteThread, and OpenProcess suggests it can launch other programs or inject code into running processes, which is a common behavior for malware that wants to execute payloads stealthily.

The imports from ADVAPI32.dll, OpenProcessToken, LookupPrivilegeValueA, and AdjustTokenPrivileges suggest that the program attempts to manipulate privileges, likely to elevate its access rights. This could allow the malware to bypass security controls or perform actions that require administrative privileges.

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

On the host side, one of the clearest indicators is the creation of additional executables. The strings show multiple suspicious file names, such as winup.exe, wupdmgr.exe, and wupdmgrd.exe, which are clearly intended to blend into legitimate Windows Update components. These file names are not actual Windows binaries, yet they are placed in system directories like \system32, which is a major red flag. Any appearance of these files on disk would signal compromise. The malware also uses APIs like FindResourceA, LoadResource, WriteFile, and MoveFileA to extract an embedded secondary executable from its own resources and drop it to disk. This behavior means that host‑based monitoring tools could detect the creation or modification of files in system directories, unusual file writes originating from a suspicious process, or unexpected execution of binaries masquerading as Windows Update components.

Privilege escalation attempts also provide useful host indicators. The main executable imports OpenProcessToken, LookupPrivilegeValueA, and AdjustTokenPrivileges specifically to enable SeDebugPrivilege, which allows the malware to tamper with other processes. Legitimate software rarely enables this privilege unless it performs advanced debugging or system‑level tasks. Any process unexpectedly enabling SeDebugPrivilege would therefore be highly suspicious and could be used as a behavioral detection indicator.

Network‑based indicators are even more direct, since the embedded second‑stage executable includes URLDownloadToFileA from urlmon.dll and contains a hardcoded download URL: http://www.practicalmalwareanalysis.com/updater.exe. In a real attack, this would point to an attacker‑controlled server hosting additional payloads. Any outbound HTTP request to an unusual or untrusted domain , especially one requesting a file named “updater.exe”, would be a clear sign of an infection attempt.

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?

To analyze the resource, I used binwalk, which revealed that the executable contains another PE file embedded inside its resource section. This aligns perfectly with the earlier strings output that hinted at an additional payload bundled within the binary.

Examining the extracted resource confirms that the executable is acting as a dropper. The embedded PE is a fully functional Windows executable rather than configuration data or benign assets such as icons or dialogs. This indicates that the primary executable’s role is to unpack and deploy a second-stage payload at runtime. The use of Windows API functions such as GetTempPathA, GetWindowsDirectoryA, and WinExec further supports this behavior, as they allow the malware to write the extracted file to disk, likely in a temporary or system directory—and then execute it. This technique is commonly used to evade static detection by separating the loader logic from the main malicious payload.

Additionally, the presence of the hardcoded URL and the URLDownloadToFileA import suggests that the embedded resource may serve as an intermediate stage, whose purpose is to download or update the final payload from the network. Even if the embedded executable itself is detected, the malware can still change its behavior by hosting a different payload at the remote location. This layered design increases resilience against signature-based defenses and allows attackers to update their malware without redistributing the original dropper.