This malware installs a service by the name of MalService, as evident from the string and the call to CreateServiceA. The service is created by sub_401040. One parameter in the CreateServiceA call that stands out is dwStartType, which is set to 2. According to Microsoft documentation, this corresponds to SERVICE_AUTO_START, meaning the service is automatically started by the Service Control Manager during system startup. This allows the malware to persist across reboots.
The malware first attempts to open a mutex named HGL345. If the mutex already exists, the program immediately exits. If it does not exist, the malware creates it. This ensures that only a single instance of the malware runs at any given time and prevents multiple instances from interfering with each other or duplicating activity.
One good host-based signature is the presence of the MalService service on the system. Another strong indicator is the mutex named HGL345, which is unique and created by the malware to enforce single-instance execution. Additionally, the program sets up a waitable timer using a SYSTEMTIME structure with the year set to 2100. This extremely far-future date is an anti-analysis technique intended to prevent the payload from executing during dynamic analysis. While the system clock is not actually modified, the unusual timer configuration itself can be used as a behavioral signature.
After the waitable timer is satisfied or bypassed, the service creates 20 threads, all executing the same function, StartAddress. This function uses the WININET library to create an Internet session with the user agent set to Internet Explorer 8.0, then enters an infinite loop repeatedly accessing the website http://www.malwareanalysisbook.com. Since the user agent string is not reliable, a strong network-based signature would be repeated or continuous HTTP requests to that domain, especially at an unusually high frequency.
This program functions as a simple DDoS-style malware. Its primary purpose is not to compromise the victim system further, but to generate a high volume of HTTP traffic toward a specific website in an attempt to overwhelm or disrupt it.
The program does not terminate on its own. After performing its setup and thread creation, it calls Sleep with an infinite timeout, causing the process to remain running indefinitely unless it is externally terminated.
This program does not achieve persistence. It initializes COM, creates a COM object, performs its intended action, and then exits. There are no registry modifications, services, scheduled tasks, or startup mechanisms implemented.
This program instantiates a COM object using the IID D30C1661-CDAF-11D0-8A3E-00C04FC9E26E, which corresponds to the IWebBrowser2 interface. Using the CLSID 0002DF01-0000-0000-C000-000000000046, which represents the Internet Explorer WebBrowser COM object, the program launches an Internet Explorer instance through COM automation and navigates to the web page “http://www.malwareanalysisbook.com/ad.html”. This behavior is consistent with adware-like functionality, as it forces a browser instance to load a specific advertisement page without user interaction.
The program finishes execution immediately after invoking the COM method to load the web page. It then frees allocated memory, uninitializes COM, and exits normally.
Starting with static analysis, the imported functions of the executable indicate file manipulation, directory traversal, and advanced file operations using APIs such as MapViewOfFile and CreateFileMappingA. Strings such as C:\Windows\System32\Kernel32.dll and the slightly altered kerne132.dll immediately raise suspicion. Although no networking DLLs are directly imported by the executable, this is explained by the fact that the malware ships with its own DLL. An initial import scan of the DLL reveals network and socket functionality through WS2_32.dll. All of this suggests that the executable acts as a loader, while the DLL contains the primary malicious logic.
Executing the malware inside a virtual machine initially produces no visible behavior. Further reversing reveals that the executable expects a specific command-line argument before executing its payload: WARNING_THIS_WILL_DESTROY_YOUR_MACHINE. When the program is run again with this argument, the malicious behavior is triggered.
This time, Procmon shows a very large number of events associated with the executable, totaling approximately 12,674 events. These events indicate extensive directory traversal across the entire C drive. Closer inspection shows that while many directories are enumerated, only executable files are actually opened and modified. To confirm that file modification occurred, I selected nc.exe from the victim VM and compared its hash to that of a freshly installed version. As expected, the hashes differed, confirming that the file had been altered.
Using the string kerne132.dll as a clue, I suspected that import table patching was occurring. Specifically, Kernel32.dll was being replaced in the import table with kerne132.dll. Examining the modified nc.exe confirms this, as the original import from the legitimate Kernel32.dll is replaced with an import from the malicious kerne132.dll.
Procmon further shows that this DLL is written by the executable into the System32 directory with a file size of 65,536 bytes. The initial assumption was that this DLL was identical to the one bundled with the malware. However, comparing the hash of the dropped DLL with the original bundled DLL shows a mismatch. Interestingly, comparing the dropped DLL’s hash with the DLL present on the compromised system after infection results in a match, indicating that the DLL is modified during or after deployment.
This malware achieves persistence by installing a malicious DLL into the System32 directory that closely resembles Kernel32.dll in name. It then patches the import table of executable files on the system to load this malicious DLL instead of the legitimate one. As a result, any affected executable will automatically load and execute the attacker’s code whenever it runs, providing persistent execution without the need for additional startup mechanisms or registry modifications.
The file Kerne132.dll is the biggest host-based signature we could achieve. The only problem is we shoould use both the before compromise and after compormise signatures. Also any import string matching that dll in any exe is a viable signature that should be directly flagged.
This malware acts as a loader and propagator for a malicious DLL by patching executables on the victim system. It modifies every .exe it finds to replace imports of kernel32.dll with a malicious look‑alike DLL placed in System32, effectively achieving a large‑scale DLL hijacking / import table patching. As a result, any infected executable will load the attacker’s DLL and execute malicious code automatically.
The dropped DLL implements a simple network backdoor. It connects to 127.26.152.13:80, sends the string “hello”, and then waits for commands from the attacker. The received input is parsed and matched against supported commands, including:
Although it may seem counter‑intuitive, the malware’s own executable logic can be leveraged for remediation. Since the infection mechanism works by patching executables to replace kernel32.dll imports with a malicious kerne132.dll, the process can be reversed.
There are two viable approaches:
After restoring the imports, the malicious DLL should be deleted from System32 (this step is highly recommended to prevent reinfection). Finally, a system reboot is required to terminate any processes that are still running code from the hijacked DLL.
This remediation works because the malware does not appear to implement persistence beyond import‑table patching and a globally loaded DLL, making full cleanup possible once all executables are repaired.