Hytale Supply Chain Attack

![[hytale-diagram-banner-3x.png| Hytale Malware Attack - Execution Chain]]

Introduction

In March 2026, a campaign targeting the Hytale gaming community was identified through network traffic analysis. Threat actors deployed a typosquatted domain replicating the official site pixel by pixel, distributing a trojanized installer disguised as Hytale Launcher Setup to exploit a player base that has been eagerly awaiting the title’s release for years.

What initially appeared to be a standard phishing operation revealed, upon deeper investigation, a multi-stage infection chain of unusual sophistication. The campaign chains two installers, trojanizes a Lua library loaded via direct PE Import Table patching, executes PIC shellcode from within the .text section without new memory allocations, hides a Java payload via steganography inside a game image file, and injects it directly into the JVM through JNI, all within a trusted process, leaving no artifacts on disk.

This report documents the full execution chain, the evasion techniques employed, and the indicators of compromise identified during the investigation.

Note: This report was originally written for an external publication that never responded. The formal writing style reflects that original intent.

Key Takeaways

• Supply chain attack via typosquatting targeting a specific gaming community
• Dual-installer architecture (NSIS + Inno Setup) replicating the legitimate installation flow
• PE Import Table patching on HytaleClient.exe to force loading of a trojanized Lua library
• PIC shellcode embedded in the .text section with no additional memory allocation
• Steganography applied to an official game image to conceal a heavily obfuscated Java class
• Direct JNI injection into the JVM of the java-original.exe process
• Initial discovery through anomalous network behavior: java-original.exe maintaining a TCP connection in ESTABLISHED state on port 1336

Discovery

The investigation started from a network traffic anomaly observed after installing the binary. The process java-original.exe was maintaining a TCP connection in ESTABLISHED state on an unexpected port, a behavior that prompted deeper inspection of the entire installation chain.

The campaign employs a fraudulent domain registered through typosquatting that replicates the visual identity of the official infrastructure to lure victims into downloading a malicious binary named Hytale Launcher Setup. This domain is the victim’s first point of contact with the campaign.

![[Hytale-site.png| Typosquatted Hytale site]]

To maximize infection rates, the attackers removed friction barriers present on the legitimate site. Payment sections and login flows were stripped out in favor of a direct “100% free” download promise, reducing the victim’s evaluation time and maintaining the visual deception from the very first interaction.

Initial Infection Vector

The initial infection vector consists of an installation package that closely replicates the interface and visual identity of the legitimate Hytale installer.

![[installer-comparison.png | Original vs malicious installer]]

The initial binary, identified by SHA256 9229e9cf6e19ec75c2bd8dd7faa373bf074e54d44880a1ba339e6e55f2b1ed77, was built using NSIS (Nullsoft Scriptable Install System), a legitimate open-source installer framework commonly abused by threat actors for malware packaging.

The operation proceeds through a multi-stage execution structure designed both to overcome file size limitations and to fragment the malicious context across distinct components, complicating isolated analysis of each stage.

Stage 1 - Interface and Configuration (NSIS). The 1.6 GB initial binary manages the graphical interface and deploys the launcher executables into %AppData%\Roaming. NSIS is chosen for this stage specifically to replicate the original assets (banners, icons), circumventing user suspicion. However, NSIS is technically limited to packages under ~2 GB.

Stage 2 - Asset Deployment (Inno Setup). After the first stage completes, execution passes to HytaleInstaller.exe (1.2 GB). This component uses Inno Setup to deploy a 3.3 GB Assets.zip file, working around the NSIS size limitation.

![[inno-setup-stage2.png | Inno Setup second-stage installer]]

Upon completion, the installer creates a desktop shortcut and automatically launches Hytale F2P Launcher.exe. This dual-installer architecture is a deliberate approach to maintain the fraudulent interface while managing the deployment of large data volumes onto the system that will subsequently be compromised.

The F2P Hytale Facade (SanHost)

The malicious artifact uses the open-source Hytale F2P-EVO project as a technical facade. Originally hosted on GitHub (amiayweb/Hytale-F2P) with over 500 stars, the project received a DMCA Takedown from Hypixel Studios in February 2026, resulting in the removal of the main repository and all 60+ forks under piracy and copyright infringement claims.

![[dmca-takedown-notice.png | DMCA takedown notice]]

To circumvent the legal action, the project was migrated to a private infrastructure at SanHost (sanhost.net), maintaining its own repositories at git.sanhost.net. The repository was still publicly accessible at the time of this analysis.

By embedding this functional, legitimate software, the attackers add a layer of technical plausibility to the artifact. When users observe that the game and launcher actually work, they tend to dismiss potential security warnings, allowing the attack chain to operate in the background unimpeded.

Modified Import Directory

After the installation flow completes, a shortcut for the Hytale Launcher is created on the desktop. Upon execution, the first anomaly is immediately visible: the “Play” button is already available without any additional downloads. This behavior indicates that the game assets were pre-deployed during the setup process, prompting direct inspection of the \Client directory for undocumented modifications.

![[f2p-launcher-play-button.png | F2P Launcher with Play button available]]

Upon clicking Play, the game launches and runs normally, reinforcing the perception of a legitimate installation.

![[hytale-game-running.png | Hytale game running]]

Investigation of the \Client directory revealed the executable HytaleClient.exe. While the binary displays a digital signature issued by Hypixel Studios Canada Inc using SHA256 with an SSL.com timestamp countersignature, Windows marks the signature as invalid.

![[invalid-digital-signature.png | Invalid digital signature on HytaleClient.exe]]

Analysis Note: The original F2P-EVO project also invalidates the signature as part of its authentication bypass modifications. However, the version distributed by this campaign introduces additional artifacts that are absent from the official SanHost repository, confirming that the modifications extend beyond the scope of the legitimate fork.

Unlike the structure found in either the legitimate launcher or the original SanHost fork, two suspicious dynamic libraries were identified in the client root directory, specifically sqlite3.dll and luah54.dll.

Their presence is notable because of Hytale’s native protection system. The game implements integrity verification that, upon detecting discrepancies in dynamic libraries or DLL Proxying attempts, terminates execution with the error “Identity token signature verification failed”.

![[integrity-verification-error.png | Integrity verification error]]

To bypass this barrier, the attackers went beyond DLL Search Order Hijacking. They applied PE Import Table patching directly on HytaleClient.exe, physically modifying the binary structure to declare luah54.dll as a known legitimate dependency to the Windows PE loader.

![[import-table-comparison.png | Import Directory Table comparison]]

The mechanism exploited here is the PE loader’s trust model. When verifying dependency integrity, Hytale’s protection system queries entries declared in the executable’s Import Directory Table. Since luah54.dll was inserted directly into this structure, it is treated as a legitimate dependency declared by the binary itself, loaded by the PE loader before any application-level integrity check can execute. The malicious code enters the process at the same trust level as any official dependency.

With the entry vector established, the analysis moves to the content of the injected library.

Trojanized Library - Native Code Orchestration

Analysis of luah54.dll revealed a sophisticated behavioral obfuscation approach. The binary exposes 156 exports and 116 imports, counts consistent with a full build of the official Lua library compiled from lua.org source code.

Unlike typical malicious DLLs that merely imitate a legitimate library name, this version preserves all the functions, symbols, and structures of a real Lua library, making detection through static import analysis nearly impossible.

VirusTotal detection at the time of analysis reinforces this assessment: luah54.dll was flagged by 0/72 engines.

![[luah54-virustotal.png | VirusTotal detection for luah54.dll (0/72)]]

Evidence of the next stage in the chain was found through a string search within luah54.dll itself.

![[luah54-string-references.png | String references in luah54.dll]]

The search for sqlite3 reveals two relevant entries, the direct reference sqlite3.dll and the full hardcoded path to the payload. This path is the link connecting the two chain stages, the exact address from which luah54.dll will load the next malicious component into the target process.

Within the DllMain, on processing the DLL_PROCESS_ATTACH event, the dllmain_dispatch function redirects execution to sub_180014200. This function spawns the stager routine in a separate thread via _beginthread.

![[dllmain-to-beginthread.png | DllMain to _beginthread execution flow]]

Once executed, the thread invokes the malicious subroutine sub_180014230.

![[stager-path-resolution.png | sub_180014230 path resolution]]

This function retrieves the %APPDATA% path, constructs the full path to sqlite3.dll using the hardcoded path identified earlier, and copies the string java-original.exe as the target process name. Resolution of LoadLibraryA is performed dynamically via GetProcAddress on KERNEL32.DLL, preventing the function name from appearing in the DLL’s static Import Address Table.

Inside sub_180014230, a while(true) loop continuously monitors the system for the java-original.exe process.

![[dll-injection-loop.png | Process monitoring and DLL injection loop]]

Once the target process is located, the artifact performs DLL injection. The code allocates memory within the address space of java-original.exe, writes the payload path, and uses CreateRemoteThread to invoke LoadLibraryA, resulting in the loading of sqlite3.dll into the address space of java-original.exe.

PIC Shellcode in the .text Section

Deeper analysis of sqlite3.dll revealed a nearly identical critical execution flow within its DllMain. The diagram below illustrates the call chain leading to the final stager execution.

![[dllmain-to-createthread.png | DllMain to CreateThread call chain]]

The flow converges at sub_180106840, which uses CreateThread to spawn a new execution thread. The critical technical detail lies in its entry point, sub_180001000, which corresponds exactly to the start address of the binary’s .text section (0x180001000).

![[pic-shellcode-text-section.png | PIC shellcode at .text section start]]

This approach is strategic. By pointing the thread directly to code already present in the .text section, the artifact executes Position-Independent Code (PIC) shellcode without requiring new memory allocations, without needing APIs like VirtualAllocEx and eliminating the creation of PRIVATE/RWX unbacked memory regions, which are the primary target of modern memory scanners and EDR solutions.

This distinction is significant when compared to Stephen Fewer’s Reflective DLL Injection (RDI), which has been widely adopted for over a decade. RDI necessarily creates a new PRIVATE/MAPPED memory region with excessive permissions, a characteristic that virtually all modern EDRs actively monitor. The method used here executes shellcode within the already-mapped address space backed by sqlite3.dll on disk, rendering the region indistinguishable from legitimate code to scanners based on memory attributes.

VirusTotal detection also reflects this evasion profile: sqlite3.dll was flagged by 1/72 engines, with a single generic Cynet verdict.

![[sqlite3-virustotal.png | VirusTotal detection for sqlite3.dll (1/72)]]

JNI Injection and Steganography

Continuing the PIC shellcode analysis, it was confirmed that the artifact does not use a static Import Address Table. All critical API resolution is performed dynamically at runtime, expected behavior for Position-Independent Code.

![[dynamic-api-resolution.png | Dynamic API resolution engine]]

The routine sub_180001024 serves as the symbol resolution engine, mapping critical functions from kernel32.dll and Java libraries. Among the resolved APIs, the following stand out: VirtualAlloc and VirtualFree for memory manipulation, LoadLibraryA, GetProcAddress, and FreeLibrary for module loading, and GetEnvironmentVariableW alongside JNI_GetCreatedJavaVMs for Java interaction.

The presence of JNI_GetCreatedJavaVMs confirms the artifact’s final objective, which is to locate and infiltrate active Java Virtual Machine instances within the host process. In this same routine, the shellcode also references the full hardcoded path to the image file used for steganography:

sanasol\f2p-evo\data\games\15faf9c0-7369-49c9-bc52-7dffb78de983\Client\Data\Game\Interface\MainMenu\5e7a961d5e334000189a2a78_6.png

Further into the shellcode, one of the most sophisticated aspects of this sample was identified. The routine sub_1800025db uses steganography to conceal the final stage, loading gdiplus.dll to process the referenced image file.

![[gdiplus-steganography.png | GDI+ resolution for steganography]]

The routine resolves and uses the following GDI+ functions: GdiplusStartup, GdiplusShutdown, GdipCreateBitmapFromFile, GdipGetImageWidth, GdipGetImageHeight, and GdipBitmapGetPixel.

The processed file is not a generic container crafted by the attackers. It is 5e7a961d5e334000189a2a78_6.png, official Hytale artwork used in the game’s main menu interface.

![[steganography-carrier.png | Steganography carrier image]]

This image-as-a-container technique prevents the payload from being detected by disk-based signatures, since the malicious data is encoded within the pixel color structure of a PNG, indistinguishable from legitimate visual content.

Monitoring the DLL loading flow in the java-original.exe process via Process Monitor confirmed the expected loading sequence.

![[procmon-dll-loading.png | DLL loading sequence in Process Monitor]]

The process java-original.exe loads sqlite3.dll first, followed immediately by GdiPlus.dll. Examining the call stack of the loading event:

![[loadlibrary-call-stack.png | LoadLibraryA call stack]]

The call stack confirms that sqlite3.dll invoked LoadLibraryA to load GdiPlus.dll, exactly as predicted by the static analysis of the shellcode.

Memory Extraction via GDI+ Lifecycle Interception

To extract the payload via steganography, a dynamic interception strategy based on the GDI+ object lifecycle was implemented. By monitoring gdiplus.dll calls, it was determined that the moment of highest data integrity occurs immediately before the graphics resources are released by GdipDisposeImage.

The first step was to confirm the loading of the necessary libraries in the process, validating the execution context.

![[windbg-loaded-libraries.png | WinDbg loaded libraries]]

A breakpoint was then set on the function responsible for releasing the image.

![[gdip-dispose-breakpoint.png | GdipDisposeImage breakpoint]]

The call stack at the breakpoint confirmed that execution was within the expected flow, with GdipDisposeImage being called from sqlite3+0x309d.

![[gdip-dispose-call-stack.png | GdipDisposeImage call stack]]

With the breakpoint hit, register inspection revealed that RDX pointed to 0x0000019f7e5f0000, the memory address where the payload was already fully assembled.

![[payload-register-state.png | Register state with payload address]]

The resulting dump confirmed 340 KB of Java bytecode in a RW (read-write) memory region.

![[java-bytecode-dump.png | Assembled Java bytecode dump]]

By placing the breakpoint on GdipDisposeImage immediately after the pixel processing loop completed, it was possible to wait for the extraction routine to finish and perform the memory dump at the exact moment the Java bytecode was fully assembled.

This maneuver was essential to neutralize the self-destruction routine identified in the malware code, which executes a secure wipe of the bytes in memory immediately after use, designed to prevent artifact recovery.

Payload Lifetime and Forensic Implications

What makes this operation effective against forensic analysis is the short lifetime of the payload in raw data memory. Once the bytecode is handed to the JVM, execution context transitions across three stages.

JVM Abstraction. When the class is registered for execution, the JVM maps raw bytecode into internal runtime structures. At that point, the original extraction buffer is no longer required for normal control flow.

Adaptive Execution (Interpreter and JIT). The JVM may execute the class through interpretation and progressively compile hot paths into native code. This further decouples runtime behavior from the original extracted byte sequence.

Post-Execution Evasion. In parallel, the loader performs a secure wipe of the extraction buffer and sensitive path/string artifacts.

As a result, the malware remains active inside the JVM while analyst visibility into the original bytecode artifact is significantly reduced. The class is not literally invisible, but the recovery window becomes very narrow and highly timing-dependent, with the pristine payload still preserved only inside the steganographic carrier image in game assets.

Without the dump performed in the precise interval between buffer assembly and JVM integration, recovery of the artifact would have been nearly impossible.

Extracted Java Class Analysis

After successful extraction of the .class file from memory, static analysis via decompilation revealed a scenario of aggressive obfuscation. The artifact employs advanced techniques to prevent code readability and defeat control flow analysis.

![[skidfuscator-obfuscated-class.png | Skidfuscator-obfuscated Java class]]

The presence of a nothing_to_see_here constant containing ASCII art (a “Rick Astley” representation) within the static block is a characteristic signature of Skidfuscator, a high-complexity Java obfuscation engine that, at the time of this writing, has no publicly available deobfuscator.

Unlike simple obfuscators that merely rename variables, Skidfuscator is designed with a focus on resilience against reverse engineering. Its defenses include non-linear control flow through fragmented logic blocks with opaque arithmetic, and homoglyph identifiers using visually ambiguous characters (I, l, 1) to impede manual analysis.

![[skidfuscator-ascii-art.png | Skidfuscator ASCII art signature]]

Detection of this protection confirms that the malware developer invested in defeating conventional analysis, requiring dynamic analysis or emulation techniques to understand the class’s actual behavior.

Artifact Reconstruction

Extracting raw data from memory requires restoring the .class file integrity to enable dynamic monitoring. This process presents two main obstacles, bytecode obfuscation and memory alignment issues.

The first obstacle is duplicate method obfuscation. Standard execution of the dumped file fails with java.lang.ClassFormatError: Duplicate method name. This technique deliberately violates JVM specifications by inserting methods with identical names and signatures, blocking verification and conventional decompilation.

![[classformat-error-duplicate.png | ClassFormatError from duplicate methods]]

However, Java game launchers are frequently started with -Xverify:none or -noverify flags to bypass bytecode verification that would conflict with legitimate mod and patch modifications. If the original process’s JVM was started with this configuration, it accepts the obfuscated bytecode without restrictions. This explains why the class executes correctly in the target process and makes the use of this flag indispensable for reproducing execution in a controlled environment.

The second obstacle is trailing padding. Unlike files on disk, memory buffers frequently contain null bytes beyond the end of the actual file structure. Since the JVM requires the exact binary size to load a class, any extra data causes Extra bytes at the end of class file, even with verification disabled.

![[trailing-null-bytes-removal.png | Trailing null bytes removal]]

The solution involves manual removal of trailing null bytes identified through hexadecimal analysis, restoring the correct .class file alignment.

After alignment adjustment and verification suppression, the payload was validated and executed successfully.

![[payload-execution-success.png | Successful payload execution]]

Sandbox Analysis and C2 Communication

Controlled execution of the malicious Java class in a sandbox environment allowed observation of the full payload behavior, confirming and expanding the hypotheses raised during static analysis.

The complete installer chain was not executed directly inside ANY.RUN. The original setup packages were multi-gigabyte files, the later stages depended on specific on-disk paths for both the DLL and the PNG payload, and the native loader expected the target Java process to be named java-original.exe. The sandbox-provided Java runtime was also limited to Java 8, which was not suitable for reliably executing the recovered Java stage.

To reproduce the final stage under controlled conditions, the analysis used a minimal execution harness containing a compatible OpenJDK runtime and the extracted class under the expected layout: latest\bin\lIlIllIlIlI.class and latest\bin\java-original.exe. The harness launched the payload with latest\bin\java-original.exe -noverify -cp latest\bin lIlIllIlIlI. This setup was used strictly to observe the Java-stage runtime behavior and C2 communication. It does not represent the original delivery or installation flow.

The first relevant data point is the score assigned by the ANY.RUN sandbox to the java-original.exe process, 10 out of 100, with no verdict. This number does not represent a failure of the analysis environment. In a constrained setup like this, execution that shows potentially suspicious traits may still avoid an immediate malicious verdict.

![[anyrun-score.png | ANY.RUN score 10/100]]

Immediately after initialization, the process registers three artifacts on disk, all related to persistence infrastructure and input hooking.

![[malicious-file-artifacts.png | Malicious file system artifacts]]

The file jnh40 is extracted to C:\Users\admin\.plugins\libraries, a hidden directory created by the malware itself. The file JNativeHook-2.1.0.x86_64.dll is deposited in %TEMP%. Both are components of the open-source JNativeHook library, which provides system-level global keyboard and mouse hooking capabilities independent of window focus.

![[jnativehook-globalscreen.png | GlobalScreen event listeners]]

Analysis of the jnh40 library confirms the org.jnativehook package with the GlobalScreen class, which registers global listeners for NativeKeyEvent and NativeMouseEvent. This is the campaign’s keylogging and mouse monitoring implementation, where every keystroke and click performed by the user, in any application, is captured by the global hook registered in the game’s JVM.

With the hook established, the process initiates communication with the command and control infrastructure. The first packet transmitted to the C2 is the classic RAT registration beacon, following a structured victim identification protocol.

![[c2-registration-beacon.png | C2 registration beacon]]

The beacon transmits the compromised machine’s username, operating system, host process name and PID, and language and region settings. After victim registration, the client sends the hooking module load confirmation.

![[c2-plugin-confirmation.png | Plugin load confirmation]]

The message confirms that the JNativeHook plugin was initialized successfully. The hash de6cf300c801226d4b19e4fdc258975e corresponds to the MD5 of the jnh40 module extracted to C:\Users\admin\.plugins\libraries, functioning as an integrity check of the loaded component. The presence of this verification mechanism indicates a C2 infrastructure with active control over modules deployed to victims.

Network traffic analysis reveals the two connections established by the process.

![[c2-tcp-connections.png | C2 TCP connections]]

The first connection, to 172.66.171.73:443, corresponds to the domain pastebin.com via Cloudflare, likely used for configuration retrieval or staging of additional modules. Since the connection is encrypted over HTTPS, only the destination was observable; the specific Pastebin URL and its contents could not be determined from the captured traffic. The second connection, to 212.64.210.140 on port 1336, is allocated to the SUNUCUN ASN, a Turkish hosting provider.

This is the primary C2 connection and constitutes infrastructure evidence of campaign activity through hosting in Turkey; on its own, this does not provide conclusive attribution to Turkey-based threat actors.

Conclusion

This campaign demonstrates a rare example of holistic evasion engineering. Every technique employed exists to eliminate a specific detection layer, culminating in fully fileless Java execution within a trusted game process where distinguishing malicious code from legitimate execution becomes significantly harder for memory scanners, EDRs, and forensic tooling.

The PE Import Table patching neutralizes application-level integrity verification. The trojanized Lua library provides a legitimate execution context for the stager. PIC shellcode executing from the .text section avoids the memory allocation artifacts that modern EDRs monitor. Steganography within an official game asset prevents disk-based signature detection. JNI injection into an already-running JVM eliminates process creation artifacts. The post-execution bytecode wipe destroys the forensic evidence window.

None of these techniques are new individually. The sophistication here lies in their composition. A carefully layered sequence where each technique exists specifically to cover the detection gap that the previous one leaves exposed.

As defenses evolve, campaigns like this one make it clear that detection will need to keep pace, though how to achieve that without generating excessive false positives remains an open problem.

MITRE ATT&CK Mapping

Indicators of Compromise

Tools Used