Xurum: New Magento Campaign Discovered

Digital commerce is a widely targeted industry for cybercriminals in general, but Magento’s widespread popularity has unfortunately made it an especially appealing (and lucrative) target. The most notable specific attack is Magecart,  in which the attackers aim to deploy JavaScript-based skimmers to illicitly acquire sensitive user information. These Magecart threat actors take advantage of well-known web vulnerabilities to achieve this acquisition.

There have been at least seven threat groups that have targeted Magento shops since 2015, which speaks to the prominence of the platform and the success the threat actors have achieved through this exploit.

In early 2022, the CVE-2022-24086 vulnerability came to light, enabling attackers to exploit the Magento template engine and execute arbitrary PHP code on susceptible targets. The exploit operates through multiple steps, with common attack vectors involving the abuse of either the check-out process or the wishlist functionality. Since its disclosure, this vulnerability has emerged as a primary entry point for numerous Magecart actors who are targeting vulnerable Magento 2 shops.

Over the past few months, Akamai has been closely monitoring a focused campaign that specifically targets a relatively small number of Magento deployments. We dubbed the campaign Xurum to reference the domain name of the C2 server utilized by the attackers.

During the ongoing campaign, we observed attackers attempting to execute two distinct payloads from a total of four IP addresses (Figure 1). These IPs are associated with the infrastructure of two hosting providers: Hetzner in Germany and Shock Hosting in the United States.

During our investigation of the server xurum.com, it became evident that it is physically located in the Netherlands (Figure 4) and hosted by the Russian hosting company called VDSina.ru (Figure 5).

As there are several iterations of this attack, we opted to call it xurum to distinguish this campaign from others.

Frequently, attackers employ distinct naming conventions for their domains or malware, which inadvertently or deliberately serve as their distinctive signature. During our investigation into the possible meaning of "xurum," we came across two potential interpretations.

According to Google Translate, xurum is defined as "right" in Latin, implying "doing the right thing" (Figure 7). On the other hand, WordSense Dictionary indicates that xurum is the word for “boy” in an extinct language once spoken in Guatemala (Figure 8).

Please note that, as of writing this blog post, the attackers have taken down their xurum server and transitioned to another one that appears to still be in the quality assurance phase.

The malicious PHP script that is being downloaded from the xurum server and executed on the victim machine has several infection stages.

First of all, it collects technical information about the victim, such as:

• PHP version

• Whether the exploit landed in the “/pub” directory (common directory structure in Magento)

• Whether the “/var/www/html/vendor/magento/google-shopping-ads/registration.php”  file exists and is writable 

• The contents of “env.php” file, which includes crucial information of the Magento application, like environment-specific settings, but also secrets like the encryption key used to secure sensitive data like passwords, credit card details, and customer information

Then, it decodes a Base64 obfuscated blob and writes it to the “/var/www/html/vendor/magento/google-shopping-ads/registration.php” file (Figure 9).

The new file contains intriguing content. Rather than maintaining their own copy of a web shell and hosting it on their C2 server, the code in the new file points to a public GitHub repository owned by a security researcher named "Bad Advertiser" or "@0xbadad”. Inside this repository, there is a known web shell named wso-ng. What makes this especially interesting, however, is that the web shell is not being written to the server's disk. Instead, it is fetched and executed only in memory when the newly created page "registration.php" is accessed. To further protect against unauthorized access, attackers also require the presence of a specific "magemojo000" cookie in the request for the web shell to execute successfully.

Then the attacker registers the new web shell functionality as a new Magento component masked as “GoogleShoppingAds” (Figure 10).

After installing the backdoor, the attackers retrieve information about the sales order payment methods in the past 10 days and exfiltrate this data to their xurum.com drop zone, along with the previously collected technical information (Figure 11).

In the final step, the attackers create a backdoor admin user with the name "mageworx" (or "mageplaza" in some variations). These names correspond to popular Magento 2 extension stores, Mageworx and Mageplaza (Figure 12). This choice of names appears to be an attempt to camouflage their actions as something legitimate related to these reputable extension providers.

Note an interesting nuance in the backdoor user email addresses. There is a double “z” in “mageplazza” in the email address developer@mageplazza.com, while the legitimate store domain has a single “z” in its name mageplaza.com, which seems like a typo by the attackers. A similar typo was made in the other backdoor user email address: support@magaworx.com,  with an “a” instead of an “e” as in the original store name Mageworx.

A web shell is a malicious script or piece of code that attackers upload and execute on a web server to gain unauthorized access and control over the server and its underlying files and data in a persistent manner.

In this operation, the attackers are leveraging the very advanced web shell named wso-ng, which as mentioned above, was created by a security researcher several years ago. As stated by the author, wso-ng is a new generation of the older and famous WSO (which stands for Web Shell by Orb). 

In addition to the typical functionality found in web shells, such as system information gathering and file and SQL management, wso-ng has other remarkable features that make it stand out (Figure 13).

One of these new features is the concealed login page. Upon accessing the page, it responds with a 404 Not Found HTTP status code, giving the impression of a nonexistent page. The visible content appears to be blank at first glance (Figure 14). However, upon inspecting the page source code, it reveals a hidden login form.

The form is cleverly hidden from the viewer using a straightforward CSS trick, where it is shifted 1,000 pixels to the left, effectively keeping it out of the visible area. This hidden login form is designed to wait for the user to type in the password.

We found another interesting tool in the attackers’ arsenal on the xurum.com server: a public exploit of an older CVE-2016-5195 named Dirty COW for Linux local privilege escalations (Figure 15).

Since many of our web application firewall (WAF) customers effectively mitigated this campaign, we did not directly observe further actions taken by the threat actors. However, during our investigation, we noticed website names that were indirectly related to this campaign, and showed in the origin/referer HTTP header of the exploit request.

At least one of these websites was infected with a simple web skimmer. The skimmer was installed on the main page, and didn’t apply any obfuscation techniques. It would collect credit card information and extract to a drop zone hosted on “smileface.site” (Figure 16).

Upon attempted access, this website responds with a cold “Get out!” message (Figure 17).

The IP information shows the server is located in Moscow and hosted by the Russian “reg.ru” hosting (Figure 18).

Our investigation into this campaign indicates that it dates back to at least the end of January 2023. The attackers have shown a meticulous approach, targeting specific Magento 2 instances rather than indiscriminately spraying their exploits across the internet. They demonstrate a high level of expertise in Magento and invest considerable time in understanding its internals, setting up attack infrastructure, and testing their exploits on real targets.

This campaign serves as a practical example of how older vulnerabilities continue to be exploited years after disclosure, as businesses struggle to keep up with patches and security measures.

To prevent initial server access, security practitioners are advised to stay updated with the latest patches and complement them with the implementation of a WAF, such as Akamai App & API Protector.

Since the primary objective of these Magecart threat actors is to infect Magento pages with web skimmers and steal customers' credit card information, additional dedicated security solutions are strongly recommended. These solutions should provide visibility into browser script behaviors and offer defense against client-side attacks.

An effective approach involves deploying security measures closer to where the actual attacks on clients occur. This includes identifying attempted reads from sensitive input fields and data exfiltration. We suggest promptly collecting these events to facilitate rapid and efficient mitigation with the help of security products such as Client-Side Protection & Compliance.

During our analysis of recent Magento CVE-2022-24086 exploitation attempts on our customers, we discovered additional campaigns that are currently under investigation. We will continue to investigate further and share our findings with the security community. For more breaking security research, follow us on Twitter.

The following indicators of compromise (IOCs) are presented to help the community detect the malicious activity described in the post.