Technical Analysis

Overview

The attack starts when a victim lands on one of these AI-themed websites. These websites are optimized to rank highly in Google search results for trending AI-related topics through Black Hat SEO techniques. For instance, if a user searches for a query like "Luma AI blog," the malicious page often appears as one of the top results, as shown in the figure below.

Figure 1: Example Google search result for AI-based topics leading to malware.

Once the victim clicks on the search result, a webpage similar to the following will appear:

Figure 2: Example AI-themed website designed to lure victims into installing malware.

Once the victim visits the page, malicious JavaScript is triggered, collecting browser data, encrypting it with XOR, and sending it to the attacker-controlled domain gettrunkhomuto[.]info. The threat actor’s server decrypts the data, verifies the information, and responds with a 302 redirect to an intermediate site. The intermediate site provides JavaScript that checks the victim’s public IP to determine the final destination, often redirecting to another webpage hosting malware payloads like Vidar Stealer, Lumma Stealer, or Legion Loader.

On revisits, the redirection behavior may change, instead sending the victim to download adware or Potentially Unwanted Applications (PUA) as part of an alternative monetization scheme.

Malicious JavaScript

The deceptive blog pages are embedded with JavaScript that is triggered whenever the user clicks anywhere on the webpage. The Javascript is hosted on AWS CloudFront, a trusted content delivery network (CDN). CloudFront is typically used by legitimate websites to serve web content like HTML, CSS, and JavaScript, but threat actors misuse it to make their activities appear legitimate and harder to detect. The JavaScript is designed to perform several key tasks, which are described in the following sections.

AdBlocker detection

Once triggered, the JavaScript runs alongside the webpage content. It checks for the presence of ad blockers or DNS guards in the user’s browser, as these tools could block the redirection process the threat actors depend on to deliver malware. The script identifies the following adblockers: 

Table 1: List of ad blocker names checked by the JavaScript.

If any of the ad blocker names are found, then the JavaScript will not redirect users to the malware download page.

Configuration decoding

The JavaScript retrieved from AWS CloudFront stores important configuration details, such as domain information for redirecting users, in Base64-encoded strings (with a custom character set). This encoding method obscures the malicious domains and helps the threat actors evade detection. Once decoded, these parameters enable the redirection process that eventually leads users to a malware delivery site.

Collected data encryption

After the JavaScript collects information from the victim’s browser, it sends the information to the threat actor’s server as a GET request, embedded in the URL. The server uses the data to generate a redirection link that leads the victim to the malware download page. 

To protect the data being sent, the threat actors encrypt it using a randomly generated XOR key. This key is Base64-encoded (using the standard character set) along with the encrypted data, the first five bytes of the Base64-decoded string represent the XOR key. This process ensures the data appears obfuscated, making detection and monitoring more difficult. The table below outlines the information sent to the redirection server:

Table 2: List of information sent to the redirecting server.

The process for encrypting the URL GET request involves the following steps:

Step 1: Add a validation parameter

The script checks if the query string in the GET request contains the parameter valid=1. If the parameter is absent, the JavaScript appends valid=1 to the end of the query string to mark the request as valid for processing.

Step 2: XOR encryption of query string

The query string is encrypted using a randomly generated 5-byte XOR key. Each character in the query string is XOR’ed with its corresponding key character. 

Step 3: Combine XOR key and result

The final result is created by combining the XOR key with the XOR-encrypted query string. It is then Base64-encoded (again with standard Base64 encoding) to generate the output URL.

Example input:

var d = "VsWg8"; // Randomly generated XOR key
var b = "https://getrunkhomuto[.]info"; // Base URL
var c = "?cs=N0hvY2wEcFlWWQ54XlNZBnxcUlk&abt=0&red=1&sm=16&k=home&v=1.34.36.4&sts=2&prn=0&emb=0&tid=1072626&rxy=1920_1080&inc=8&u=2199064996573029&agec=1742719364&fs=1&mbkb=75.642965204236&ref=https%3A%2F%2Fchat-gpt-5.ai%2F&jst=0&enr=0&lcua=mozilla%2F5.0%20(windows%20nt%2010.0%3B%20win64%3B%20x64)%20applewebkit%2F537.36%20(khtml%2C%20like%20gecko)%20chrome%2F131.0.0.0%20safari%2F537.36&tzd=-7&uloc=&if=0&ct=3&ctc=0&_CR5c=1742721475304&utr1=00:03:198&utr2=38&utr3=0&utr4=0&utr5=0&utr6=0&utr7=0"; // Query string

Example output:

https://getrunkhomuto[.]info/VnNXZzhpECRadmYbIT4KITY0IVQBJAZSDA4fGT16OAs0MlQ9VTYFTGtDcRVdMk5mQUs7TmZRHj1OPwhVM1UhWgl4QGNJC2BdY0FLIgBqVR4mATlaCHAWOgUFZlUjDlxrQmdQCmBBYUFKLgpqVgFkQwhWCG5DcQ5WNU5vQU1rQWZeAWZFY14BYEZgVAhkSnEGXzMQalYPYkFgVgFlRWNBXiVOZkFVNBg1Wg9jXWFTCm9FYlUIYkFkUR4kFjFaUCIHJxQdZTJyVX5zQREEUDcHegBIIl5iSVk%2FVmUhHjwAI1oIcBY5FQVmVTsETTdOOghCPx87Bh1kNWJJCHNBZ09PPx0zCE8lVmVXViJWZVcJZl1nQgsUVmVXTz8dYVMdZTFyVQguRWNOHWRDNhdIOhYgAlo9GiNCChBGZFAWZUVyVQh%2BGD8TVTpWZSQdZEM7DlMzVmVXXzMQPAgRc0FnBFAkHDoCHWQ1ZlQJeEN5VxZmVmVXSzcVNhVRc0ERUgthXWRRHiIJM1oVYVUiC1c1TnEOXmtDcQRMa0BxBEw1TmdBZxUhYgQFZ0RjVQ9kQmNQDWVDY0FNIgFmWghmSWdUAmdKb0FNIgFlWgtuVSITSmVOZ0FNIgFjWghwBiMVDWtDcRJMJEVqVx4jByVQBWZVIQZUPxdqVg%3D%3D

Notably, getrunkhomuto[.]info, which serves as the base URL of the GET request, has been linked to multiple deceptive sites. ThreatLabz has observed over 4.4 million hits associated with this domain since January 2025. 

The domain gettrunkhomuto[.]info is a vital component in the redirection chain. It validates and processes encrypted requests, coordinates redirections, and filters targets based on collected data.

Malware observed 

The techniques used in this campaign have the potential to distribute various types of malware. During our analysis, we identified the following malware attack chains.

Vidar and Lumma Stealer   

The final download pages in this campaign deliver Vidar Stealer and Lumma Stealer as password-protected ZIP archives, with the password provided on the final downloading page. Once extracted, they contain an 800MB NSIS installer, a deceptively large size intended to appear legitimate and bypass detection systems with file size limitations.

The attack chain for both Lumma and Vidar Stealer share a similar structure. The NSIS installer includes files with a .docm extension embedded in different folders. While the extension suggests that the files are Microsoft Word macro-enabled documents, they are in fact components of the malware payload. Upon execution of the NSIS installer, these files are combined in the proper sequence to generate an AutoIT loader executable and an obfuscated AutoIT script, which act as the delivery mechanism for the malware payload (e.g., Lumma or Vidar Stealer).

To evade detection, the threat actors implement antivirus checks within the NSIS script using Windows utilities like tasklist and findstr. These tools are employed to detect and terminate specific antivirus processes running on the victim's system to avoid interruption. The targeted antivirus software includes:

• Quick Heal (opssvc)
• Webroot (wrsa)
• Sophos (SophosHealth)
• BitDefender (bdservicehost)
• Avast (AvastUI)
• AVG (AVGUI)
• Norton Security (nsWscSvc)
• ESET (ekrn)

Figure 3: The attack chain illustrating the distribution process of Lumma and Vidar Stealer. 

Legion Loader

The malware delivery process for Legion Loader begins by directing users to download a ZIP archive which contains another password-protected ZIP archive, along with an image file displaying the password needed to unlock it. Once unpacked, the final ZIP archive contains an MSI file that serves as the Legion Loader payload.

The figure below shows the attack chain for Legion Loader:

Figure 4: An attack chain for Legion Loader as observed in this campaign.

Upon execution, the MSI file installs itself in the AppData directory and deploys various decoy software programs such as Tao Raiqsuv Utils, Frankwo Utilities, Heizer Kroop Sortic, or Kraew Loop Sols. During installation, the MSI file performs several custom actions, including launching a genuine installer executable as a decoy to conceal its operations. 

In the steps below, we explain the custom actions executed during the installation of the MSI file.

Data collection and communication (DataUploader.dll)

During the installation of the MSI file, DataUploader.dll is executed using a custom action to perform several key operations critical in the attack chain:

• Collects and transmits information to C2 server: In this version of Legion Loader, the DataUploader DLL includes a single export function named SendCollectedData. This function collects key information, such as the date and Product ID, and transmits it to the C2 server via an HTTP POST request.
• Processes the server response (status code): Upon receiving a C2 server response with the HTTP status code 200 (OK), the system uses the MsiSetPropertyW function to update the MSI file’s status. This update confirms that the data transmission and processing were successful and the attack proceeds to the next stage.
• Retrieves encrypted RAR file password: To facilitate the next phase of the attack, the system retrieves a password from the server. This password is then saved for later use via MsiSetPropertyW. Unlike earlier versions that relied on hardcoded passwords within the MSI file, this dynamic password may complicate static detections.

• Extracts files via 7ip: The BAT file invokes 7zip (7z.exe) passing the password that was previously obtained from the C2 server to decompress an archive file.
• Extracted file contents: The extracted archive contains a malicious DLL file, accompanied by legitimate DLLs or executable files that create an appearance of legitimacy to avoid detection.
• Executes legitimate software to sideload malicious DLL: To stage the attack, the BAT file executes a genuine, trusted executable, which is used to sideload the malicious DLL file. This technique ensures that the malicious DLL is loaded into the memory of a legitimate process to reduce suspicion.
• DLL injection via process hollowing: After being loaded into a legitimate process, the malicious DLL injects itself into a newly created instance of explorer.exe using process hollowing. During this process, the legitimate code in explorer.exe is replaced with malicious code. 

Shellcode execution and payload delivery: Once the code injection is complete, the embedded shellcode is executed within the hollowed-out explorer.exe process which is explorer.exe. In the campaign observed by ThreatLabz, the shellcode executed a browser extension designed to steal cryptocurrency.