{
	"id": "1dbb1b03-ad6e-4aa2-b68d-21730a4a9c63",
	"created_at": "2026-04-06T00:14:38.569285Z",
	"updated_at": "2026-04-10T03:20:19.130448Z",
	"deleted_at": null,
	"sha1_hash": "9662dc18bf8091e28f7da9fe5655451d9ba530a6",
	"title": "How We Seized 15 Active Ransomware Campaigns Targeting Linux File Storage Servers",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3473560,
	"plain_text": "How We Seized 15 Active Ransomware Campaigns Targeting\r\nLinux File Storage Servers\r\nBy Ignacio Sanmillan\r\nPublished: 2019-07-10 · Archived: 2026-04-05 20:25:05 UTC\r\nIntroduction\r\nIt is rare to see ransomware being used to target the Linux operating system. However, cyber criminals seem to\r\nadapt to this emerging environment and use a variety of creative methods to gain profits from this landscape.\r\nWe at Intezer have detected and temporarily DoS’d the operation of a ransomware targeting Linux-based file\r\nstorage systems (NAS servers).\r\nWe have named the ransomware QNAPCrypt, as this is the name the authors have appeared to label the malware.\r\nQNAP is a well-known vendor for selling NAS servers, which the malware was intended to infect and encrypt the\r\ncontaining files for ransom. NAS servers normally store large amounts of important data and files, which make\r\nthem a valuable target for attackers and especially a viable target for ransomware campaigns.\r\nThis malware currently has very low detection rates in all major security solutions.\r\nThe first two sections of this blog post will explain in brief how QNAPCrypt operates and how we were able to\r\ntake advantage of two design flaws in the ransomware infrastructure in order to temporarily stop the campaign—\r\npreventing the malware from infecting additional victims and forcing the authors behind this malware to deploy\r\nnew instances. Lastly, we will present a detailed technical analysis of the malware and the investigation of the\r\nentire campaign.\r\nFor reference, here is the genetic analysis of the QNAPCrypt malware:\r\nARM variant\r\nx86 variant\r\nHow the Ransomware Works\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 1 of 17\n\nThe QNAPCrypt ransomware works similarly to other ransomware, including encrypting all files and delivering a\r\nransom note. However, there are several important differences:\r\n1. The ransom note was included solely as a text file, without any message on the screen—naturally, because it is\r\na server and not an endpoint.\r\n2. Every victim is provided with a different, unique Bitcoin wallet—this could help the attackers avoid being\r\ntraced.\r\n3. Once a victim is compromised, the malware requests a wallet address and a public RSA key from the command\r\nand control server (C\u0026C) before file encryption.\r\nHow We Seized the Campaign\r\nIn order to further research the malware and its operation, we wrote a script to simulate infections on a wide scale\r\nto see how the wallet generation mechanism worked in the attackers’ back end.\r\nAfter simulating the infections of hundreds of virtual “victims”, we discovered two major design flaws in the\r\nransomware infrastructure which led us to seize the operation:\r\n1. The list of bitcoin wallets was created in advance and it was static. Therefore, it does not create a new wallet for\r\neach new victim in real time, but rather it pulls a wallet address from a fixed, predetermined list.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 2 of 17\n\n2. Once all of the wallets are allocated (or sent), the ransomware would not be able to continue its malicious\r\noperation in the victim’s machine.\r\nAfter simulating the infection of more than 1,091 victims from 15 different campaigns, we encountered that the\r\nattackers ran out of unique Bitcoin wallets to supply to their victims. As a result, any future infection will be\r\nunsuccessful and the authors behind this malware were forced to update their implants in order to circumvent this\r\ndesign flaw in their infrastructure to continue with their malicious operations.\r\nAfter several days of continuously DoS’ing their infrastructure, we have observed a newer variant in the wild that\r\nshares a significant amount of code with previous QNAPCrypt instances and Linux.Rex. This time, the newer\r\nvariant uses an embedded static wallet and RSA public key in contrast to previous instances.\r\nTechnical Analysis\r\nThe initial implant we found came in the form of a statically linked Golang binary built with the Go linker for\r\nARM architecture. Throughout our research, we were able to confirm that other variants exist for additional\r\narchitectures such as x86 / x64.\r\nGo binaries may seem difficult to analyze when they come stripped, since trying to make sense of stripped\r\nstatically linked binaries is usually a more difficult task than analyzing stripped dynamically linked binaries.\r\nWe can observe that this binary is indeed a Go executable by looking at the section names in its section header\r\ntable.\r\nIf we know the location of these sections, in particular the .gopclntab section, we will be able to reconstruct\r\nsymbol names and offsets. This methodology is illustrated in the following diagram:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 3 of 17\n\nFor further insights into populating function names in Go binaries we highly recommend to view Tim Strazzere’s\r\npresentation and scripts in GitHub which document this technique.\r\nAfter retrieving Go function names, analyzing the binary becomes much less complex since we can highlight the\r\nrelevant functions of the application. Let’s not forget that the binary is 4MB in size.\r\nAfter several cryptography algorithm initializations and parsing of arguments for directory whitelisting and alike\r\nfunctionalities, the malware will send a GET request to the CNC as a means to communicate that a new victim has\r\nbeen compromised and that system locking is taking place:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 4 of 17\n\nAfter sending this GET request, the malware will attempt to retrieve victim keys configuration using a client for\r\nthe SOCKS proxy protocol version 5.\r\nThis proxy will request to connect to an onion domain name. The following represents the relevant packets for this\r\nconnection:\r\nAfter successful connection through the proxy to the onion domain, an additional GET request to the ransomware\r\nREST API is completed in order to retrieve the RSA public key that will be used to encrypt the file system—a\r\nunique Bitcoin wallet and the ransom note specific to the victim. All of these artifacts seem to be retrieved based\r\non a specific campaign ID.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 5 of 17\n\nThe response from the server is the following:\r\nAfter victim configuration has been retrieved, the malware will proceed to remove itself and then it will parse the\r\nretrieved RSA public key.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 6 of 17\n\nThis RSA public key will be used to encrypt a random sequence of bytes that would be used to encrypt the file\r\nsystem later on. This encrypted key will be base64 encoded and it will be written at the end of the ransom note file\r\ncalled README_FOR_DECRYPT.txt. We also noted that the ransomware distributes a different Bitcoin wallet\r\nper each compromised system:\r\nAfter this file is created, the malware will proceed to execute the locking mechanism by walking the file system\r\nencrypting files using AES CFB with the derived encrypted key, avoiding to encrypt the ransom note just created:\r\nThe malware will target files with the following extensions:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 7 of 17\n\nAfter encryption, the malware will rename the affected files so that they will be prefixed with ‘.encrypt’:\r\nIn order for system decryption to take place the base64 encoded random sequence encrypted with the RSA public\r\nkey will be needed to be sent to the ransomware operator via the onion domain site after paying the demanded\r\nransom:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 8 of 17\n\nAfter system locking has taken place, the ransomware will communicate that it has finished with the victim once\r\nagain to the CNC:\r\nLooking Outside of the Binary\r\nOne of our intended goals that we wanted to achieve when analyzing QNAPCrypt was to assess the scale of\r\nvictims the ransomware was dealing with.\r\nWe were able to find a Reddit thread in which we contacted some of the affected victims:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 9 of 17\n\nWhile talking to some of the victims related to the various campaigns of this malware, we were able to identify the\r\ninitial attack vector as SSH brute force attacks and that they were targeting mainly NAS server providers, which\r\ncorresponds to how the attacker has chosen to label this malware:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 10 of 17\n\nAfter making these findings we studied their infrastructure to determine if there was anything we could do to\r\ninteract with this threat actor’s operations.\r\nWhile researching the ARM instance of the malware, we observed that there was a request through their REST\r\nAPI in order to retrieve new victim configuration keys as previously discussed. The following diagram is a high\r\nlevel overview of the ransomware operation:\r\nThe connection to the SOCKS5 proxy is completed without any authentication enforced, and anyone would have\r\nthe capability to connect to it.\r\nTherefore, we decided to interact with the ransomware infrastructure in order to retrieve configuration keys and\r\npotentially temporarily shut down the operation of the ransomware to prevent infection of future victims that were\r\ncompromised by instances of the ransomware that followed the previous design architecture:\r\nThis idea simply abuses the fact that no authentication is enforced to connect to the SOCKS5 proxy as previously\r\nmentioned. Since the authors behind this ransomware were delivering one Bitcoin wallet per victim from a static\r\npool of already generated wallets, we could replicate the infection packets to retrieve all of the wallets until they\r\nhad no further wallets under their control. Therefore, when a genuine infection would occur, the ransom client\r\nwould not be able to retrieve configuration artifacts.\r\nWe wrote the following script in order to implement the methodology described above:\r\nimport socket\r\nimport hexdump\r\nimport json\r\nimport sys\r\nHOST = '192.99.206.61'\r\nPORT = 65000\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 11 of 17\n\nfor i in range(15):\r\n BTC_WALLETS = list()\r\n while True:\r\n s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\r\n s.connect((HOST, PORT))\r\n \r\n s.send(b'x05x01x00')\r\n data = s.recv(1024)\r\n hexdump.hexdump(data)\r\n \r\n s.send(b'x05x01x00x03x16' + b'sg3dwqfpnr4sl5hh.onionx00' + b'x50')\r\n data = s.recv(1024)\r\n hexdump.hexdump(data)\r\n \r\n s.send(b'GET /api/GetAvailKeysByCampId/%.2d HTTP/1.1x0dx0a' % i +\r\n b'Host: sg3dwqfpnr4sl5hh.onionx0dx0a' +\r\n b'User-Agent: http/2x0dx0a' +\r\n b'Accept-Encoding: gzipx0ax0dx0a')\r\n data = s.recv(1024)\r\n print '[+] Campaign id %.2d' % i\r\n hexdump.hexdump(data)\r\n try:\r\n data = json.loads(data[data.find('{'):])\r\n print data['BtcPublicKey']\r\n s.close()\r\n \r\n if data['BtcPublicKey'] not in BTC_WALLETS:\r\n BTC_WALLETS.append(data['BtcPublicKey'])\r\n else:\r\n sys.exit()\r\n except ValueError as e:\r\n print \"[+] CAMPAIN HAS NO WALLETS LEFT\"\r\n with open(\"wallets_%0d.txt\" % i, 'w+') as fd:\r\n for wallet in BTC_WALLETS:\r\n fd.write(wallet+'n')\r\n break\r\nWe were able to collect a total of 1,091 unique wallets meant to be delivered to new victims distributed among 15\r\ndifferent campaigns.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 12 of 17\n\nFurthermore, by depleting the attacker’s stored Bitcoin wallets we were able to stop this malware from infecting\r\nnew victims temporarily, since if there is a failure to parse the RSA public key the client will just exit:\r\nThe following screenshot shows the packets that the onion domain will retrieve after the entire static Bitcoin\r\nwallet pool was depleted:\r\nThe HTTP request returns a 200 but with a content length of 0, therefore failing to retrieve configuration, and thus\r\nthe ransomware client stops execution. This implies that we were able to identify an easy method to prevent\r\nfurther infections of this ransomware by constantly depleting its static bitcoin wallet pool.\r\nAttribution and Attackers Reaction\r\nAfter several days of continuously DoS’ing QNAPCrypt clients, we encountered another QNAPCrypt sample—\r\nbut this time targeting x86 systems.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 13 of 17\n\nBased on Genetic Malware Analysis, we observed that this specific implant reused a large portion of code with old\r\ninstances of x86 Linux.Rex builds. Linux.Rex is known for deploying exploits against Drupal servers in 2016, in\r\norder to conduct ransomware and DDoS operations.\r\nThe following represents some of the code similarities between Linux.Rex and newer QNAPCrypt variants:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 14 of 17\n\nAlthough both implants implement different functionality, it is noticeable that both were written in a similar\r\nmanner.\r\nFurthermore, we can observe similarities with the ARM instance of QNAPCrypt but with a major difference—the\r\nRSA public key, Bitcoin wallet and ransom note are hardcoded in the binary:\r\nWe can also see that the hardcoded onion domain is exactly the same as in the ARM variant, and the site design to\r\npay the ransom is also the same, although the demanded ransom in Bitcoin seems to be lower than in previous\r\nvariants:\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 15 of 17\n\nWe interpret the discovery of these newer instances with hardcoded configuration to be a response from the threat\r\nactors behind this campaign to attempt to circumvent the DoS that their non connectionless instances were\r\nsuffering. This implied that they were forced to change their implants and to centralize their bitcoin wallets,\r\nmaking the tracking of their income via their ransomware campaigns more convenient.\r\nConclusion\r\nWe have covered the operation of the QNAPCrypt ransomware, and how we were able to find design flaws to\r\nprevent the malware from running in newer victims’ machines and forcing the attackers behind the malware to\r\nupdate their implants in order to circumvent these flaws.\r\nAdditionally, Golang malware seems to be on the rise, since it appears to be a very convenient language to create\r\ncross-platform malware.\r\nFurthermore, we have discussed how Linux ransomware has slightly different targets than Windows ransomware,\r\nin this case targeting NAS servers rather than Linux endpoints.\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 16 of 17\n\nUnfortunately detection rates of QNAPCrypt are low, and the ransomware could create significant monetary\r\nlosses and economic damage in comparison to other types of Linux threats.\r\nWe have created a custom YARA signature for detecting future variants of QNAPCrypt.\r\nGenetic Analysis\r\nThe QNAPCrypt malware variants are now indexed in Intezer’s genetic database. If you have a suspicious file that\r\nyou suspect to be QNAPCrypt or other malware from the Rex group, you can upload it to Intezer Analyze to\r\ndetect code reuse to this threat family and many others. You are welcome to try it for free in our community\r\nedition.\r\nGenetic Analysis of the QNAPCrypt ARM variant\r\nIOCs\r\nsg3dwqfpnr4sl5hh[.]onion\r\n192.99.206[.]61\r\n3d7ebe73319a3435293838296fbb86c2e920fd0ccc9169285cc2c4d7fa3f120d\r\n076a6fa4e051c061e19b9e3e37da9c63a9bc7c1a99111ac13b32eb2f70b7fa5c\r\nSource: https://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nhttps://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.intezer.com/blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers/"
	],
	"report_names": [
		"blog-seizing-15-active-ransomware-campaigns-targeting-linux-file-storage-servers"
	],
	"threat_actors": [],
	"ts_created_at": 1775434478,
	"ts_updated_at": 1775791219,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9662dc18bf8091e28f7da9fe5655451d9ba530a6.pdf",
		"text": "https://archive.orkl.eu/9662dc18bf8091e28f7da9fe5655451d9ba530a6.txt",
		"img": "https://archive.orkl.eu/9662dc18bf8091e28f7da9fe5655451d9ba530a6.jpg"
	}
}