Malvertising campaign targeting IT teams with MadMxShell

Zscaler Blog

Malvertising campaign targeting IT teams with MadMxShell

Introduction

Beginning in March of 2024, Zscaler ThreatLabz observed a threat actor weaponizing a cluster of domains masquerading as legitimate IP scanner software sites to distribute a previously unseen backdoor. The threat actor registered multiple look-alike domains using a typosquatting technique and leveraged Google Ads to push these domains to the top of search engine results targeting specific search keywords, thereby luring victims to visit these sites.

The newly discovered backdoor uses several techniques such as multiple stages of DLL sideloading, abusing the DNS protocol for communicating with the command-and-control (C2) server, and evading memory forensics security solutions. We named this backdoor "MadMxShell" for its use of DNS MX queries for C2 communication and its very short interval between C2 requests.

In this blog, we will examine the campaign details, threat actor's infrastructure, and a detailed technical analysis of the backdoor. We have also shared a custom Python script to decode C2 traffic for malware samples and all the Indicators of Compromise (IOCs) linked to this campaign.

Key Takeaways

• Between November 2023 and March 2024, multiple domains were registered by a threat actor spoofing legitimate IP scanners and other software typically used by IT security and network administration teams in enterprises.
• The threat actor abused Google Ads to conduct a malvertising campaign in an attempt to push their malicious sites to the top of search results.
• A successful infection results in the delivery of a previously unseen backdoor that we named "MadMxShell".
• The backdoor uses techniques such as multiple stages of DLL sideloading and DNS tunneling for command-and-control (C2) communication as a means to evade endpoint and network security solutions, respectively.
• In addition, the backdoor uses evasive techniques like anti-dumping to prevent memory analysis and hinder forensics security solutions.

Background

The selection of spoofed software by this threat actor suggests that their targets primarily consist of IT professionals, particularly those in IT security and network administration roles. This aligns with the recent trend observed where advanced persistent threat (APT) groups, such as NOBELIUM, crafted attacks targeting these teams. With their privileged access to internal systems and networks, IT security and network management teams are attractive targets for both APT groups and initial access brokers (IABs) that sell access to compromised networks. Although we have not yet attributed the attack described in this blog to a specific threat actor, it is important to highlight this emerging trend.

Threat actors have previously leveraged Google malvertising to distribute trojanized versions of a specific port scanning tool called Advanced IP Scanner, as described in reports by Kaspersky, BlackBerry, and Huntress.

Although the campaign discussed in this blog uses a similar distribution method, the range of spoofed software has been expanded beyond Advanced IP Scanner. Furthermore, to the best of our knowledge, the final malware delivered in this campaign has not been publicly documented before. Due to these significant differences, we assess with a high-confidence level that this campaign was conducted by a different threat actor.

Attack Chain

The figure below illustrates the multi-stage attack chain at a high level.

Figure 1: The MadMxShell end-to-end attack-chain, which starts with malvertising, followed by multiple intermediate stages of DLL sideloading, and finally DNS tunneling to the C2 server.

Technical Analysis

In the following section, we provide a detailed analysis for each stage of the attack chain.

Google malvertising campaign

The modus operandi of the threat actor includes registering multiple look-alike domains spoofing popular port scanning software and pushing them to the top of Google search results by running Google Ads campaigns. This technique is widely known as malvertising.

During our investigation, we observed users being served these ads when they searched for keywords related to any of the following:

• Any of the legitimate port scanning and IT management software spoofed by this threat actor
  • Advanced IP Scanner
  • Angry IP Scanner
  • PRTG IP Scanner by Paessler
  • Manage Engine
• Network admin tasks related to virtual local area networks (VLANs)
• Scanning IP protocol

The figure below shows details of the Google Ads campaign carried out by the threat actor in March 2024 for one of the malicious domains. The domain in question was advanced-ip-scanz[.]net, and the search keywords were:

• "advanced ip scanner"
• "ip address scanner"

Figure 2: Details of the Google Ads campaign in March 2024 for the malicious domain advanced-ip-scanz[.]net.

Once the user clicks on any of the attacker-controlled Google Ads, they are redirected to a look-alike site for the corresponding IP scanning software.

Malicious sites

The threat actor registered multiple sites masquerading as legitimate IP and port scanner software programs. One such site we observed is advansed-ip-scanner[.]net, which is a look-alike site of the legitimate Advanced IP scanner software www.advanced-ip-scanner[.]com.

The complete source code of the fraudulent website mirrors the legitimate site, with the exception of minor edits made by the threat actor to JavaScript (JS) code which redirects the user to download a malicious file when they click the download button.

The figure below shows a comparison between the altered JS code from the malicious file and the original legitimate website. The createFunctionWithTimeout function was modified to redirect users to download a malicious ZIP archive file from the following URL:
advansed-ip-scanner[.]net/yftyudruo.php.

Figure 3: JavaScript code comparison between the legitimate website's createFunctionWithTimeout function and the malicious website's code.

Backdoor Details - Binary Analysis

Stage 1 injector

The analysis in this blog is based on this ZIP archive: Advanced-ip-scanner.zip (SHA256:7966ee1ae9042e7345a55aa98ddeb4f39133216438d67461c7ee39864292e015).

The ZIP archive contains two files:

• Advanced-ip-scanner.exe: A renamed copy of the legitimate Microsoft EXE oleview.exe.
• IVIEWERS.dll: A 22 MB DLL, which contains the stage two payload. This DLL is padded with an unused overlay of 10 MB which prevents scanning by security products that limit the size of analyzed files.

When Advanced-ip-scanner.exe is run, it sideloads IVIEWERS.dll which executes a series of heavily obfuscated shellcodes extracted from various locations within the .rsrc section of the DLL. The final shellcode extracts and decodes an executable file with the XOR key 5dsadas435235bgdsgdfbvb3253453425345gfdsgfdgdf from resource AT21 of the DLL and injects it into a new Advanced-ip-scanner.exe process via process hollowing.

Stage 2 dropper

The injected EXE file contains the next stage payloads in resource ID 202, encoded with a hardcoded 8-byte XOR key F2 09 CD 2D 85 CD 1D A3 and compressed with zlib. Each encoded byte in this resource is padded with seven null bytes, resulting in a 10MB file, likely as another anti-scanning technique. This is shown in the figure below.

Figure 4: The encoded and compressed stage 3 payload in the resource.

After decoding and decompressing the resource, two files, OneDrive.exe and Secur32.dll, are dropped into %LOCALAPPDATA%\Microsoft\OneDrive\Update.

The dropper deletes the stage 1 EXE with the following command before executing the dropped OneDrive.exe with ShellExecuteExW:

cmd.exe /C for /l %x in (0,0,0) do (ping -n 3 127.0.0.1 > NUL & for %p in ("\Advanced-ip-scanner.exe") do (del /f /q %p & if not exist %p exit))

Stage 3 launcher

OneDrive.exe, a legitimate signed Microsoft EXE, is abused to sideload Secur32.dll which sets up persistence for OneDrive.exe before executing the embedded stage 4 shellcode.

Data from Secur32.dll's icon resource ID 202 is XOR decoded to obtain the stage 4 shellcode. This is shown in the figure below.

Figure 5: The icon resource with the encoded stage 4 payload.

The first 16 bytes of the resource contain an encoded key for the payload that follows it. Each of the first 8 lowercase characters (onedrive) of the current process filename is added to every second byte of the encoded key to derive the XOR key F2 78 CD 9B 85 32 1D 07 33 C4 A0 21 98 A2 95 E3, as shown in the figure below. This prevents the correct decoding of the next stage payload if Secur32.dll was not sideloaded by OneDrive.exe.

Figure 6: Generating the XOR key to decode the stage 3 shellcode.

The malware then attempts to disable Windows Defender by setting HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware to 1 in the registry.

It configures a scheduled task named "OneDrive Update" that executes %LOCALAPPDATA%\Microsoft\OneDrive\Update\OneDrive.exe when the current user logs on to Windows before redirecting to the next stage.

Stage 4 backdoor

The shellcode is a backdoor that allows the threat actor to collect system information, execute commands via cmd.exe, and perform basic file manipulation operations such as reading, writing, and deleting files.

To deter analysis and detection, the malware decodes the code of each function with an 8-byte XOR key F2 09 CD 2D 85 CD 1D A3 (same key used in stage 2), calls the function, and then immediately re-encodes the code. In the figure below, the code excerpt on the right is decoded from the original bytes on the left. We can observe that even after decoding, it still needs to perform an additional step of decoding the get_c2_domain function before it can call it. The function code is re-encoded back to its original state before execution continues. This ensures that there is never a fully decoded copy of the shellcode in memory at any point of execution. Most sensitive strings and data, such as the C2 domain, lookup table for encoding/decoding C2 communications, and aforementioned XOR key, are also stored as stack strings to hinder analysis.

Figure 7: Function bytes before and after decoding. Note that the decoded function includes calls to decode and encode other functions called within it.

The malware generates a 4-byte session ID with the CryptGenRandom API and a victim ID by concatenating the hard disk serial number, computer name, and username, and taking the first 8 bytes of its MD5 hash.

C2 Protocol

The malware communicates with the C2 server, litterbolo[.]com, by sending requests and receiving commands encoded within DNS MX queries and responses.

The malware supports the requests described in the table below.

Table 1: A table describing the requests supported by the malware during C2 communication.

Figure 8: A diagram depicting the MadMxShell C2 communication loop.

For each session, the malware first sends a registration request (type 1) to the C2 server.

Once the C2 server acknowledges the registration request, the malware sends a heartbeat request (type 0) to the C2 server.

The C2 server will respond with any of the following commands from the table below.

Table 2: The commands and subcommands supported by the malware.

The malware then acknowledges the command with a command acknowledgement request (type 2) before executing the specified command.

After completing the commands for types 4, 5, and 6, the malware sends the results to the C2 server. The malware then repeats the entire process by sending a heartbeat request (type 0) to retrieve the next command.

Data Encoding

The malware sends requests to the C2 server by encoding the data in the subdomain(s) of the Fully Qualified Domain Name (FQDN) in a DNS MX query packet. The C2 responds similarly by encoding its commands as subdomain(s) in the corresponding DNS MX response packet.

Each byte of binary data is converted into a pair of alphanumeric characters using a custom encoding scheme involving a hardcoded 36-character lookup table. Blocks of 60 alphanumeric characters are separated by a "." character to represent a subdomain name. Python code for decoding these subdomains into the original request and C2 messages can be found in our GitHub repository.

Because the malware uses a maximum of 224 characters for the FQDN and the C2 domain name cannot be used to encode data, each DNS packet can only transfer up to 103 bytes. Requests and commands that exceed this size are split into multiple DNS packets and are sent sequentially after the other party has acknowledged receipt of the previous packet.

Possibly due to the limited bandwidth of the C2 protocol, this malware is configured with relatively short intervals (3 seconds) between requests. Because of this, its C2 traffic is significantly more noisy than the typical malware utilizing HTTP for C2 communication.

Commands received from the C2 (after decoding) are structured as shown in the table below.

Table 3: The C2 message structure.

For example, the C2 server for this sample always responds with 33qqooggxr77mdxx88jj6600ev44yyzz9bee99wwuu.litterbolo.com upon receiving a registration request. This is decoded as 00 00 00 00 03 00 0f 00 00 00 00 00 05 00 00 00 02 00 00 00 00 and represents the following message:

• Query number: 0
• Checksum: 0xF0003
• Packet number: 0
• Message length: 5
• Data: 02 00 00 00 00 (this is an acknowledgement from the C2 that it received packet 0)

Likewise, the requests sent to the C2 server (before encoding) are structured as shown in the table below.

Table 4: The request message structure.

Observed Commands

During our investigation, we observed the backdoor receiving the following commands from the C2 server:

• Collect system information (command type 4).
• Run systeminfo and ipconfig via cmd.exe (command type 5).
• Enumerate drives and specific directories, particularly the Windows system directory and user directories (command type 6).

Some of the commands were received 60 mins to 90 mins after the backdoor registered with the C2 server, which may indicate an anti-analysis technique to defeat sandboxes or actual hands-on activity by the threat actor.

Based on the capabilities of the stage 4 backdoor and the commands collected, we believe the attacker is likely interested in harvesting and exfiltrating information from infected machines. By focusing on IT teams, this threat actor can target users that have privileged access to sensitive systems (e.g., domain controllers) that can lead to a significant breach.

Infrastructure Details

Our analysis started with the domain, advansed-ip-scanner[.]net, that was live at the time of analysis and was serving a payload. WHOIS information for this domain revealed the attacker's email address used for registration to be [email protected].

A quick reverse WHOIS lookup using this email address revealed 45 domains registered between November 2023 and March 2024 to spoof various network scanning and IT management software.

The complete list of domains used for malware distribution is provided in the IOCs section at the end of this blog.

These domains were hosted on servers exclusively abused by the threat actor and belonged to the ASNs below:

• AS208312 (REDBYTES, RU)
• AS16276 (OVH, FR)

The C2 domain litterbolo[.]com used a dedicated nameserver since the malware abused the DNS protocol for C2 communication.

OSINT Research

Upon further Open-Source Intelligence (OSINT) research, we discovered two accounts created by the threat actor on criminal underground forums like blackhatworld[.]com and social-eng[.]ru using the email address [email protected].

On the blackhatworld[.]com forum, the threat actor made two posts in a thread related to someone offering methods to bypass the Google Adsense threshold. This aligns with the Google Ads abuse technique used by the threat actor to launch their own malvertising campaign.

The figures below show two posts made by the threat actor on blackhatworld[.]com expressing interest in this technique and asking to enroll in the course.

Figure 9: Posts made by the threat actor showing interest in the Google Ads abuse course.

Google Ads threshold accounts and techniques for abusing them are often traded on BlackHat forums. Many times they offer a way for the threat actor to add as many credits as possible to run Google Ads campaigns. This allows the threat actors to run campaigns without actually paying until the threshold limit. A reasonably high threshold limit lets the threat actor run the ad campaign for a significant amount of time. Once the threshold has reached, they can use the same technique with a new Google Ads account to repeat the process.

Threat actors often use virtual credit cards (VCC) along with residential proxies to verify these Google Ads accounts and employ various methods to use them up to the maximum threshold.

This approach effectively enables threat actors to run long lasting malvertising campaigns with a low investment and also avoid account suspension.

Conclusion

The threat discussed in this blog demonstrates advanced tactics, techniques, and procedures (TTPs), displaying a keen interest in targeting users in the IT security and network administration teams. The threat actor put significant effort into remaining undetected by evading memory forensics and network security controls.

While we cannot currently attribute this activity to any known threat actor, we continue to monitor any new developments associated with this threat actor and ensure the necessary protections are in place for our customers against these threats.

We also suggest users follow security best practices and exercise caution when clicking on links appearing in Google search engine results. Users must also ensure to download software only from the official website of the developer.

Zscaler Coverage

Figure 10: Zscaler sandbox detection report

In addition to sandbox detections, Zscaler's multilayered cloud security platform detects indicators related to MadMxShell at various levels with the following threat names:

Win32.Backdoor.MadMxShell

MITRE ATT&CK Framework

Appendix

Visit our GitHub repository to access the Python script to decode C2 traffic.

Explore more Zscaler blogs

Get the latest Zscaler blog updates in your inbox