Malware Analyst Series: Minecraft written by ".NET"
Introduction
Recently, I detected what appeared to be a Minecraft game written in .NET. As Minecraft is famously developed in Java, not .NET, this immediately raised suspicions. I decided to investigate further to determine what this mysterious file actually was. Link
1/ Initial Analysis
Using Detect It Easy, I performed an initial static analysis of the suspicious Minecraft.exe file. The results immediately confirmed my suspicions:
As shown in the screenshot, the file has several red flags:
It's a PE32 executable compiled with VB.NET
Uses .NET Framework/Legacy (CLR v4.0.30319)
Detect It Easy identified this as XWorm3.0-5.0 malware (obfuscated)
Has anti-analysis protection including obfuscation, modified Entry Point, bad namings
Contains anti-debugging, anti-sandbox, and anti-VM capabilities
These findings clearly indicate that this is not a legitimate Minecraft game but malicious software designed to evade detection and analysis.
2/ Deep Analysis
After identifying its basic characteristics through Detect It Easy, I decided to perform a deeper analysis to discover what it would actually do.
Since it was obfuscated, reading the function and varibles names was quite challenging. However, I found a function containing the [STAThread] tag, which allowed me to identify this function as the entrypoint of this XWorm.
a. Initialization
After identifying the entrypoint, I performed an initial analysis and renamed functions for better readability. First, it decrypts to initialize the main components that will be used later, such as the IP (hostname), port, ….
During analysis of the malware's initialization routine, I discovered an interesting function that creates a mutex:
This function creates a mutex with an obfuscated name and returns a boolean flag indicating whether the creation was successful. This is a common persistence technique used by malware to ensure only one instance runs at a time on the victim's machine.
When the malware executes, it calls this function to check if another instance is already running. If the returned flag is true, it means this is the first instance; if false, another instance already exists. This prevents multiple copies from running simultaneously, which could cause system instability or draw unwanted attention from the user or security tools.
Using mutexes is a standard technique in XWorm and many other malware families, serving both as a self-protection mechanism and a way to maintain persistence without overwhelming the infected system.
b. Anti-analysis
After ensuring this process is the only one of its kind running on the computer, it proceeds to perform a series of checks to make sure the malware can carry out its suspicious activities without being detected. If detected, it terminates the current process.
It checks whether it's running on virtual machines such as VMware or VirtualBox:
This function uses the CheckRemoteDebuggerPresent API call to determine if the current process is being debugged. By passing the handle of the current process and a reference to a flag variable, the malware can identify debugging attempts. If a debugger is detected, the function returns true, allowing the malware to alter its execution path or terminate itself to evade analysis. This is a standard anti-debugging measure used by sophisticated malware to protect itself from reverse engineering by security researchers.
The function works by checking for the presence of "sbie11.dll", a core component of Sandboxie, in the current process memory space using the GetModuleHandle API call. If this DLL is detected, the function returns true, indicating that the malware is running inside a Sandboxie environment. This detection mechanism allows the malware to alter its behavior or terminate itself when being analyzed, effectively evading detailed security analysis. This is a common defensive technique employed by sophisticated malware to remain undetected.
This function is used to check if the current OS is Windows XP, and if so, it will exit. Perhaps this malware's mechanisms work more effectively on operating systems other than Windows XP.
Finally, it performs a step that "kills two birds with one stone" by sending a request to "http://ip-api.com/line/?fields=hosting" to check the victim's internet connection and also to determine if it's operating in a sandbox environment. If the response is "true," this indicates that the malware is in a sandbox environment.
This is the response image from the any.run sandbox environment.
c. Defense Evasion
After conducting a series of checks to ensure it's not being analyzed, this malware proceeds to execute actions to evade Defender through PowerShell if it has admin privileges.
Here's a breakdown of the PowerShell parameters used by the malware:
-ExecutionPolicy Bypass: Circumvents the PowerShell execution policy restrictions, allowing the malware to run scripts regardless of system security settings.Add-MpPreference: A cmdlet specifically designed to modify Windows Defender settings.-ExclusionPath [path]: Adds the malware's current directory to Windows Defender's exclusion list, preventing any files in this location from being scanned.-ExclusionProcess [process name]: Excludes the malware's process name from Windows Defender monitoring, ensuring the running malware process remains undetected.-ExclusionPath [config.env_AppData]: Adds the malware's configuration storage location to the exclusion list, protecting its auxiliary components.
Each of these parameters plays a specific role in creating a security blind spot, allowing the malware to operate freely without detection from Windows Defender.
d. Persistence
It continues by creating another copy of itself in %AppData%.
From here it uses a persistence technique through "schtasks.exe". If the current process is running with admin privileges, it will create persistence with the highest privileges using the "/RL HIGHEST" parameter. And the entity being persisted is the minecraft.exe in %AppData% that was just created above. Here are the details of the "schtasks.exe" parameters used:
"/create /f": Creates a new task, overwriting if it already exists
"/sc minute /mo 1": Schedule to run every minute
"/tn [filename]": Task name (using the malware filename without extension)
"/tr [path]": Program to run (the malware file itself)
It also creates persistence in the registry.
In addition to scheduled tasks, the malware implements a second persistence mechanism by creating a shortcut (.lnk) file in the Windows Startup folder. This code utilizes WScript.Shell through COM Interop along with reflection techniques (LateBinding) to generate and configure the shortcut. The malware carefully sets the shortcut's target path to its copy in %AppData%, ensures it has no working directory specified, and then saves it to the Startup folder. This ensures the malware automatically executes whenever a user logs into the system. By combining both registry and startup folder persistence techniques, the malware creates redundant methods to survive reboots and removal attempts, significantly increasing its resilience against basic remediation efforts.
e. Main actions
To operate effectively, it prevents the victim from resting in order to maintain its attack actions against the victim.
To maintain activity, it uses SetThreadExecutionState with the state being ES_CONTINUOUS|ES_DISPLAY_REQUIRED|ES_SYSTEM_REQUIRED (0x80000003):
2147483651U → 0x80000003 == 0x80000000 | 0x02 | 0x01 == (ES_CONTINUOUS | ES_DISPLAY_REQUIRED | ES_SYSTEM_REQUIRED)
- Key logger
The moment of truth has arrived - from this point on, the malware creates a separate thread to carry out its malicious actions against the victim
It will hook into the keyboard through the SetWindowsHookEx function with ID 13, and this ID clearly demonstrates that it's installing a keylogger to monitor the victim's keyboard events.
_LowLevelKeyboardProc:
keyLogger function:
After capturing keys from the keyboard, they are saved to the log.tmp file in %temp%. It also clearly indicates which application the captured keys came from.
- Critical Process Protection
When XWorm gains administrator privileges, it immediately elevates its persistence to a more dangerous level by implementing critical process protection. As shown in the code snippets, the malware first checks if it has admin rights through the checkRoleIsAdmin() function. If this check succeeds, it calls a specialized function that performs three powerful actions: registers a handler for system shutdown events, enters debug mode to gain additional privileges, and most dangerously, calls RtlSetProcessIsCritical to mark itself as a critical Windows process. This designation means that any attempt to terminate the malware will trigger a Blue Screen of Death, forcing a system restart after which the malware will launch again through its persistence mechanisms. This sophisticated defense mechanism creates a frustrating cycle where conventional removal attempts actually reinforce the malware's presence, demonstrating XWorm's advanced defense capabilities and the developer's understanding of Windows internals. This protection layer is exclusively activated when the malware runs with administrator rights, highlighting why preventing privilege escalation is crucial for effective malware defense.
- Dynamic Performance Adaptation
The malware's sophisticated design includes creating a separate thread specifically for monitoring system performance and user activity. As shown in the first image, XWorm spawns a new thread with the new Thread(new ThreadStart(...)) constructor, dedicating computational resources to its performance monitoring functionality.
This thread executes the complex logic shown in the second image, which calculates user idle time by comparing the last input timestamp with the current system tick count, then converting this to a performance metric by dividing by 1000.0 and rounding the result.
The spawned thread runs in an infinite loop (for(;;)), checking this performance metric every second and dynamically adjusting the malware's operational parameters. This intelligent resource management allows XWorm to become less active when the user is working on the computer, preventing suspicious performance degradation that might alert the victim. Conversely, it intensifies its malicious activities during periods of inactivity.
This threading approach demonstrates the malware author's advanced programming knowledge, separating performance monitoring from the main malicious operations to ensure neither function interferes with the other. By implementing this resource-aware design, XWorm maintains optimal stealth while maximizing its effectiveness, representing a sophisticated approach to maintaining long-term persistence on infected systems.
- Interactive with C2 server
In the final part, this malware creates a new thread to connect and interact with the C2 server. First, it resolves the DNS to obtain the IP address of "working-begin.gl.at.ply.gg" then connects to it through port 25314. What's noteworthy is that when you visit the domain "working-begin.gl.at.ply.gg", it redirects to another legitimate site "https://playit.gg/", which could potentially cause confusion.
After successfully connecting to the C2 server, it begins sending the victim's information to the C2 server such as the operating system name, the time of malware infection (retrieved from getLastTimeWriteMalware), CPU name, and more.
Before sending data to the C2 server, the malware encrypts the data using RijndaelManaged with the key "<123456789>" and ECB mode. This is intended to prevent clear reading of the traffic which could lead to easy detection of this malware.
And surprisingly encrypt and decrypt use the same key and ECB mode
From the encrypt and decrypt functions, I have found the main function through which the C2 server will interact with the malware on the victim's machine.
This function operates like a sophisticated Remote Access Trojan (RAT), providing comprehensive remote control capabilities for the victim's machine. Through commands such as 'ping', 'close', 'uninstall', 'update' and its advanced encryption functions, the malware can perform various actions like establishing connections, closing sockets, updating malicious software, and even uninstalling itself. The control structure allows the C2 server to interact flexibly and conceal its activities optimally. Beyond basic remote control, this function also integrates dangerous features like screen capturing and launching DDoS attacks. Screen capturing enables attackers to monitor and collect sensitive victim information, while DDoS capabilities can use the infected machine to attack and overwhelm target systems. These functions transform the RAT into a multi-purpose attack tool capable of causing severe information security damage.
3/ Conclusion
IOC:
- working-begin.gl.at.ply.gg
Currently, this domain is still active, but the mastermind has changed ports multiple times, so the IoC (Indicator of Compromise) related to port 25314 may not be very valuable. Additionally, you can check VirusTotal to track more information about this IP.
First comment! Good post! You're doing great! Keep it up! <3
Amazing good job