In recent months, we observed an increase in the number of malicious campaigns that use Google Advertising as a means of distributing and delivering malware. At least two different stealers, Rhadamanthys and RedLine, were abusing the search engine promotion plan in order to deliver malicious payloads to victims’ machines. They seem to use the same technique of mimicking a website associated with well-known software like Notepad++ and Blender 3D.

The treat actors create copies of legit software websites while employing typosquatting (exploiting incorrectly spelled popular brands and company names as URLs) or combosquatting (using popular brands and company names combined with arbitrary words as URLs) to make the sites look like the real thing to the end user—the domain names allude to the original software or vendor. The design and the content of the fake web pages look the same as those of the original ones. Threat actors then pay to promote the website in the search engine in order to push it to the top search results. The technique is called “malvertising”.

Our observations

In the following snapshots, we can see Google ads promoting fake pages for AMD drivers and the Blender 3D software. If we take a closer look at the URLs, we will see that the domain names incorporate the software name but are in fact unrelated to the real AMD or Blender 3D vendors. In most cases, the top-level domains are different from those of the official sites as well. The use of less common TLDs enables the threat actors to register second-level domains that are similar to the real ones. These domains lure victims to click on the link and access the fake website more often than random domains registered in a more common domain zone, such as COM, because they may look more like a legitimate website.

Fake AMD and Blender 3D websites in search results

We visited some of the promoted sites and obtained the malicious payloads they were distributing. In this article, we will focus mainly on the “Blender 3D” fake websites.

Fake Blender 3D web pages

The size of the downloaded file (ZIP archive) is 269 MB, which is close to the original Blender installer size. The size of 257 MB stated on the fake web page matches that of the original Blender 3D installer, but it does not match the size of the fake download.

When the user clicks the “Download” button, the archive blender-3.4.1-windows-x64.zip (E0BDF36E4A7CF1B332DC42FD8914BA8B) is downloaded.

The size of the file (BBA8AA93FCDDA5AC7663E90C0EEFA2E7) extracted from the archive is 657 MB. When launched, it drops two files into the temp directory:

• The original Blender 3D MSI installer (marked green on the screenshot below), whose size is also 657 MB;
• A PE file that acts as a next-stage loader for a malicious PE file (marked red), which also has the same size as the original installer: 657 MB.

Dropped files: the original Blender 3D MSI installer and the malicious loader

The size of the dropped malicious loader is this big because it is inflated with junk bytes when the PE file is created. The deflated malicious loader size is about 330 KB, and the rest is junk.

Junk bytes inflating the loader

After the initial installer (extracted from the archive) drops these two files, it runs the malicious PE file using the CMD method (cmd.exe /c [Filename] command) to hide it from the user. Additionally, the initial installer also runs the original Blender 3D MSI to make the victim believe that the desired software is running.

Thus, the threat actors disguise their malicious payload through the installation of another software product by creating a “pre-installer” for the legitimate software, which will put both the malware and the desired genuine software on the victim’s machine.

Blender 3D installer launched by the “pre-installer”

The screenshot above shows the actual software installer running, but if we take a closer look at the processes, we will notice a short-lived sub-process (cmd.exe /c -> “SetupFileProgram”) run by the “pre-installer”. This short-lived process is the loader for the malware.

The loader

The loader is a .NET file protected by an unregistered version of .NET Reactor. It seems to use an anti-debugging technique in order to prevent a debugger from executing and dynamically analyzing the binary. In a nutshell, the loader runs a new powershell.exe process and manipulates it to execute numerous PowerShell commands, which instruct it to access a third-party URL in order to get the payload. The payload is a base64-encoded, AES-encrypted fileless binary. Further commands are related to decoding and decrypting that binary, then running it in memory, within a newly created aspnet_compiler.exe process, a legitimate Windows .NET framework compilation tool.

In this case, we observed two detection evasion tricks during the runtime:

• The fileless technique, which involves getting a payload from an online source and loading it directly into the memory of a process;
• LOLBAS (living-off-the-land binaries and scripts), which, in this case, is the use of a .NET compilation tool to run the malicious binary.

Below, we provide a more detailed analysis of the loader execution chain. After passing the loader anti-debugger, we can see that it starts a PowerShell process, so we will put a breakpoint at the CreateProcessW WinAPI call to observe the behavior.

Call of CreateProcessW to spawn a PowerShell process

Since we did not see any command passed to the PowerShell process when initializing it via the CreateProcessW call, we can conclude that it will be passed at some point later, so we can observe the passing of the PowerShell command(s) by putting a breakpoint at WinAPI WriteFile in order to see the command lines for the powershell.exe process.

So, after letting it run and reach the breakpoint, we will check the result in the return of the function call, and we can see in the stack that the first command pushed to the powershell.exe process was #Start-Sleep -seconds 30;.

Observing the pushed command(s)

We can try checking the memory section where the command is stored and searching for other commands that are being kept in the memory for later use by the loader.

Memory address of the pushed PowerShell commands

After taking all the data from this memory section, we will see all the commands passed to the powershell.exe process via the WriteFile WinAPI call.

PowerShell commands

If we read the commands, we will see exactly what the powershell.exe process is about to do. The commands instruct it to perform the following actions:

1. Download string data, which is part of the following URL, namely the name of the file: http[:]//45.93.201[.]114/docs/[RandomChars].txt. The downloaded data is a Base64-encoded string that is decoded into encrypted data.
2. Prepare the decryption method, AES-CBC, as can be seen in the screenshot above. We can also easily see and decode the Base64-encoded key and IV (initialization vector) used for decryption in the PowerShell command.
3. Decrypt the data into a Gzip-compressed binary.
4. Decompress the binary.
5. Invoke the binary to run it.

Decrypted binary

The binary that we obtained is the dropper of known malware, the RedLine stealer. The version of the stealer at hand uses an interesting technique to hide its malicious payload: it is encoded in the least significant bit of images stored in the resource section of the dropper, as well as the key and the IV bytes for its AES decryption.

Embedded images with a malicious payload

Payload decryption routine

After decrypting the payload, the dropper starts a legitimate process named “aspnet_compiler.exe”, which is part of the Microsoft .NET framework, and injects the payload into it.

Injecting a payload routine

Infrastructure

To deploy decoy pages, the malefactors register deceptive domain names, such as blender3d-software[.]net or blender3d-software[.]org. We have found more than fifty similar domains hosted at the same IP address: 91.229.23[.]200. These domain names mimic other software distribution sites as well, for example, afterburner-software[.]org, tradingviews-software[.]org, and unity-download[.]com.

The malicious payload could be stored on the same site (for example, hxxps[://]blahder3dsoft[.]store/Blender[.]rar) as the landing page or on a public service that can be used as the file hosting service (MediaFire or GitHub).

Conclusion

We are seeing an increase in the spread of malware families through Google Ads campaigns, specifically through search ads. Threat actors use fake websites to mimic legitimate software vendor websites to lure victims, and pay for ads to promote these. They use typosquatting and combosquatting for their malicious website domains, which have become common techniques in recent months. In some cases, such as the one described in this article, the threat actors also make sure to install the desired software alongside their malicious payload.

In recent campaigns, we observed mainly stealer-type malware, such as RedLine or the notorious Rhadamanthys, which is also known to use malvertising techniques to reach victims and steal data from their compromised machines.

This kind of distribution suggests that the threat actors are targeting victims, both individual and corporate, all around the world.

Indicators of Compromise