AliGater: Malvertising Chasing Users of Outdated Windows in Europe
Malvertising is one of the dark sides of pervasive advertising on the modern web that continues to retain its relevance despite attempts to curb it. Investigation of the Lumma stealer’s infection chain led us to believe that there is a new contender in the malvertising field. This new malvertising platform is mostly focused on people in Europe, particularly France and Poland. Their current campaign is exploiting known vulnerabilities in outdated versions of Chrome. This typically affects users of out-of-live versions of Windows versions, such as Windows 7, which are no longer supported with the latest Chrome versions. At the same time, our telemetry has shown us a significant increase in Magniber ransomware activity within the same timeframe, leading to a suspicion that these activities may be linked.
We have dubbed this new suspected malvertising provider AliGater. Like other malvertising platforms, they rely on legitimate ad services to redirect unsuspecting victims to their gateway. This gateway fingerprints the user, filters out potential victims and then redirects them to a malicious domain that will try to exploit vulnerabilities in their system. These exploits attempt to stealthily deploy the final payload using common tricks, such as embedding it within multiple legitimate-looking processes and threads.
We will primarily focus on identifying the main components of AliGater’s operation, used exploits and provide insight into prevalence of this new malvertising provider.
Infection Chain
The infection chain starts with an advertisement that redirects the unsuspecting victim to the initial gateway aligate.homes. This gateway fingerprints the user and, likely using the browser’s user agent, determines whether the victim may be susceptible to their exploits. Users that are identified as exploitable are redirected to a simple website mimicking a simple Google CAPTCHA. The rest are redirected to the legitimate AliExpress home page.
The purpose of this fake CAPTCHA is to fetch a JS script (captcha.js) from https://{random_chars}.{two_random_words}.shop that will fingerprint the victim’s environment (architecture, platform, WebGL, Chrome version) and send it to the C&C server. Based on this information, the C&C server will deliver a specific malicious payload tailored to the victim’s Windows and Chrome versions. This payload takes the form of an obfuscated JS with encrypted byte arrays with shellcodes. We have observed payloads containing exploits targeting JavaScript engine V8 (CVE-2023-2033) and a TrueType font parsing in Windows (CVE-2011-3402).
Chrome Exploit (stage 1)
The first encrypted buffer in the final JS contains a WebAssembly (Wasm) module which is decrypted using an XOR cipher with a variable-length key located at the beginning of the main encrypted buffer. The purpose of the Wasm module is to invoke a method that operates with an array of a different type than intended, leading to illegal access and manipulation of specific memory addresses. Consequently, the native shellcode (Stage 1) hidden in the second array is executed within the Chrome process utilizing the Wasm module.
Stage 1, invoked by the Wasm module, consists of a simple code that searches the memory of the Chrome process for the key at the beginning of the first buffer within the final JS. Once the buffer is located and decrypted, the code execution jumps to stage 2, which then tries to exploit the Windows system.
Windows Exploit (stage 2)
The Win32 TrueType font parsing is an old known exploit (CVE-2011-3402) abused by the attackers to elevate the necessary privileges for subsequent operations. If the exploit is successful, stage 2 enumerates all processes in the system and attempts to open each one. Next, it injects a third stage into the opened process.
Process Camouflage (stage 3)
The purpose of this stage is to stealthily deploy the next stage (stage 4). Stage 3 creates a new, elevated process with the well-known system process names, such as dllhost.exe, SearchIndexer.exe, spoolsv.exe, svchost.exe, and taskhost.exe, and then injects the fourth stage into this new process.
Payload Downloader (stage 4)
Fourth stage is a simple stager that downloads the next stage (stage 5) via HTTP from a hardcoded URL, which is typically formatted as http://<IP>/{two_random_words}.jpg. The IP corresponds to the DNS record of one of the *.shop servers. Note that the actual IP address may differ from the one that was used to deliver said JS script. The downloaded shellcode is not encrypted and is executed directly using the processes with elevated privileges.
Executor (stage 5)
This last AliGater stage is responsible for deploying the final payload embedded within *.jpg file that has been downloaded in the previous stage. This stage will use a two-pronged approach to deploying the final payload.
It will spawn another process from the explorer.exe processes, again from a list of well-known Windows executables (pcaui.exe, SearchIndexer.exe, svchost.exe, systray.exe, or dllhost.exe), which will be injected with the final payload. In a similar manner, it will also attempt to open another elevated process and execute the final payload from within. Therefore, the final payload may be executed twice. The final payload that has been distributed at the time of research has been identified as Lumma stealer.
Similarities to Ongoing Magniber Campaign
While researching this new threat actor, we have also noticed a spike in Magniber activity. While we were unsuccessful in retrieving the final payload of Magniber campaign through AliGater, we could not help but notice many similarities between these two campaigns. The registration date of the alligate.home domain is tightly correlated with Magniber campaign. Moreover, we have noticed multiple parallels in specific parts of the AliGater’s infection chain and Magniber. Magniber and AliGater’s stagers use unusual methods of invoking syscalls and target the same group of victims: Windows 7 systems in Europe. They also used a very similar approach to string encryption. Due to this, we strongly believe that Magniber’s codebase and the codebase used for AliGater's stagers are related. This leads to a conjecture that Magniber’s authors may have started offering their infrastructure as a service.
Command & Control Infrastructure
The C2 infrastructure is used to identify potential victims, deliver tailored exploits to their browsers and provide the final payload to be executed on the compromised machine. It consists of three key elements:
- Gateway – Facilitates initial contact and filters out potentially suspicious or unperceptive (read not exploitable) visitors before redirecting exploitable victim to a malicious domain.
- Malicious domain – Fingerprints the visitor and delivers tailored exploits and shellcodes to the victim.
- Payload distribution – Once the victim’s environment is assessed and a suitable payload is chosen, distribution endpoint will provide the final payload to the stager deployed by the exploit.
Gateway
The malicious gateway, operating at IP address 176.31.142.36 and associated with the DNS record aligate.homes (created on July 6, 2024), employs several mechanisms to manage traffic and avoid detection. The main method preventing the gate analysis is IP filtering, ensuring that repeated requests from the same IP address are not allowed – HTTP ERROR 404.
Users who are assessed as non-exploitable are redirected to the official AliExpress website using a <meta> refresh tag. However, users identified as potentially exploitable are redirected to the Malicious Domain. This redirection occurs via the HTTP 302 Found response, which includes a Location header that is dynamically generated.
Malicious Domains
The potential victim is redirected to the Malicious Domain following a specific naming convention: https://{random_chars}.{two_random_words}.shop. The two_random_words component of the domain name represents the malicious domain, which is alive approximately three days, and shares the same registrant for domains we observed. The subdomain, represented by random_chars, changes rapidly — approximately every second — to make detection and tracking more difficult.
Payload Distribution
IP addresses of the payload distribution endpoint are hardcoded within stage 4. Similarly to the same DNS where they always use the same registrant, the IP addresses belong to the same ASN number. Interestingly, these IP addresses are also frequently associated with other malicious domains of AliGater.
Detections
Our telemetry indicates that AliGater focuses primarily on outdated versions of Windows and Chrome systems. The most affected Windows versions are Windows 7 with SP1 followed by Windows 8.1. The reason behind this choice is simple – these are no longer supported by new Chrome versions, meaning that any discovered vulnerabilities are left unfixed.
The overwhelming majority of targeted systems used the following user agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36
In point of affected countries, the most prevalent locations are France and Poland, followed by Italy, Spain and Turkey. Based on this data, we assess that the European states are the campaign’s main targets.
Conclusion
AliGater is the result of an unfortunate conjunction of two phenomena. The pervasiveness of the web advertising industry makes it a ripe target for malicious actors looking for delivery vehicles for their business. Similarly, there are still a huge number of people relying on outdated versions of Windows that are inherently locked due to old, unsupported versions of Chrome (and their software in general). This combination was exploited to deliver a complex multi-stage attack vector that utilizes the ad industry to redirect victims to their infrastructure and exploit their systems to deliver Lumma stealer.
As per usual in the malvertising industry, AliGater’s infrastructure is highly dynamic, frequently cycling newly registered domains. Despite this dynamic, some patterns, such as registrants or ASN numbers, remain consistent.
We have also noticed many similarities between Magniber and AliGater’s stagers. More specifically, their coding styles have multiple similarities and use the same unusual and inherently very limiting patterns. This leads us to believe that Magniber and AliGater’s stager binaries are related. This raises a possibility that Magniber’s authors may have started to offer their infrastructure as a service. Nevertheless, due to our limited knowledge of the Magniber infection chain, we cannot provide an assessment of this conjecture.
In conclusion, AliGater’s ability to exploit outdated systems through suspicious ad services poses a significant security risk, particularly in Europe, which seems to be their primary focus. We can assume that AliGater may distribute other malware and that Magniber’s authors might expand their operation to include other threat actors. Therefore, we intend to continue monitoring their operations to understand their operation, infrastructure, and capabilities better.
