{
	"id": "24556183-77ed-4fe7-8280-cc3e4c238b81",
	"created_at": "2026-04-06T00:10:03.535319Z",
	"updated_at": "2026-04-10T13:12:43.528612Z",
	"deleted_at": null,
	"sha1_hash": "a076df8388748fe4d11827addad3497ed334b915",
	"title": "Evolution of JSWorm ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5740051,
	"plain_text": "Evolution of JSWorm ransomware\r\nBy Fedor Sinitsyn\r\nPublished: 2021-05-25 · Archived: 2026-04-05 13:55:02 UTC\r\nIntroduction\r\nOver the past few years, the ransomware threat landscape has been gradually changing. We have been witness to a\r\nparadigm shift. From the massive outbreaks of 2017, such as WannaCry, NotPetya, and Bad Rabbit, a lot of\r\nransomware actors have moved to the covert but highly profitable tactic of “big-game hunting”. News of\r\nransomware causing an outage of some global corporation’s services has now become commonplace.\r\nIn some cases, this global trend is just a reflection of the continuous life cycle of threats: old ransomware families\r\nshut down and new ones appear and pursue new targets. However, there are times when a single ransomware\r\nfamily has evolved from a mass-scale operation to a highly targeted threat – all in the span of two years. In this\r\npost we want to talk about one of those families, named JSWorm.\r\nChronology\r\nJSWorm ransomware was discovered in 2019 and since then different variants have gained notoriety under\r\nvarious names such as Nemty, Nefilim, Offwhite and several others.\r\nSeveral versions were released as part of each “rebranded” variant that altered different aspects of the code,\r\nrenamed file extensions, cryptographic schemes and encryption keys.\r\nIn the diagram below we present some of the names used by this Trojan along with the dates the corresponding\r\nvariant was actively distributed in the wild (ITW) (not the date it was first encountered). We should note that this\r\nlist is not comprehensive, but it marks the main milestones in the evolution of JSWorm.\r\nTogether with name changes, the developers of this ransomware have also been reworking their code and trying\r\ndifferent approaches to distribution.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 1 of 26\n\nAt some point in 2020 the developers even changed the programming language from C++ to Golang, completely\r\nrewriting the code from scratch. However, the similarity in the cryptographic scheme, ransom notes and use of the\r\nsame data leak website address led us to believe it’s the same campaign.\r\nThe original version of the malware, as well as some of the subsequent “rebrandings”, e.g., Nemty, were\r\nadvertised on an underground forum by a poster with the username jsworm.\r\nForum advertisement for an early JSWorm variant\r\nDistribution methods\r\nFrom its creation in 2019 until the first half of 2020, JSWorm was offered as a public RaaS and was observed\r\npropagating via:\r\nRIG exploit kit\r\nTrik botnet\r\nFake payment websites\r\nSpam campaigns\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 2 of 26\n\nFrom the first half of 2020, the public RaaS was closed and the operators switched to big-game hunting. There is\r\nevidence of an initial breach via exploitation of vulnerable server-side software (Citrix ADC) and unsecure RDP\r\naccess.\r\nTechnical details\r\nWe will describe some notable variants of the JSWorm family encountered during the history of this malware. We\r\nwon’t attempt to cover all the discovered variants of this malware as they are too numerous. The dates indicate the\r\napproximate period when the corresponding variant was observed ITW.\r\nMay 2019: JSWorm\r\nMD5: a20156344fc4832ecc1b914f7de1a922\r\nThis sample is one of the earliest discovered variants of JSWorm ransomware and, unlike its successors, it doesn’t\r\ncontain an internal version number. The sample is developed in C++ and compiled in MS Visual Studio.\r\nBesides file encryption, it performs actions such as stopping a number of running processes and services to\r\nmaximize the number of files available for encryption. In addition, it deletes all system backups, shadow copies,\r\ndisables the system recovery mode, and clears event logs.\r\nCryptographic scheme\r\nThe files are encrypted using a custom modification of a Blowfish cipher with a 256-bit key. The key is generated\r\nat the beginning of the program execution and based on concatenation of the strings: user name, device MAC\r\naddress and volume serial number (example values in the comments).\r\nKey generation process\r\nThen a string referred to by the ransom notes as “JSWORM PUBLIC KEY” is generated. In fact, asymmetric\r\ncryptography is not used here and using the word “public” makes no sense in this context. What the ransomware\r\ndeveloper is calling “JSWORM PUBLIC KEY” is in fact the aforementioned Blowfish key XOR-ed with the\r\nstring “KCQKCQKCQKCQ” and encoded in Base64.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 3 of 26\n\nXOR with the “KCQKCQKCQKCQ” key\r\nBelow is an example of key calculation, with the serial number and MAC address values chosen for illustration\r\npurposes:\r\nBlowfish key: “53385773534FE:ED:00:DE:AF:00user”\r\nPublic key after XOR: “5xpi~tfxvbx05x14qx06x15qsaqx07x14qx02x17qsa\u003e049”\r\nPublic key after conversion to Base64:\r\n“NXhwaX50Znh2Yn8FFHEGFXFzYXEHFHECF3FzYT4wNDk=”\r\nA custom version of Blowfish is used for encryption of the content of each of the victim’s files. No more than\r\n100,000 bytes are encrypted, probably to speed up encryption of large files. The encrypted data is written over the\r\noriginal.\r\nThe developers changed the internal implementation of the Blowfish cipher, which resulted in it being\r\nincompatible with standard implementations, probably in an attempt to make decryption more difficult for\r\nresearchers.\r\nAfter encrypting the contents of a file, the program renames it. An additional extension “.[ID-…]\r\n[mail@domain.tld].JSWORM” is added to the filename.\r\nEncryption flaws\r\nThe malware essentially saves the key that can be used for decryption in the ransom notes. Base64-decoding and\r\nun-xoring it is trivial, and the victim’s data can be saved without paying the ransom. Even if the ransom note is for\r\nsome reason lost, the key can be easily regenerated on the infected machine.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 4 of 26\n\nJuly 2019: JSWorm 4.0.3\r\nMD5: 5444336139b1b9df54e390b73349a168\r\nAn improved and updated version of JSWorm that attempts to fix flaws found in the previous variants.\r\nThis sample contains a language check of the infected machine. This is most likely intended to prevent encryption\r\nof data on systems where the following languages are used: RU (Russian), BE (Belarusian), UZ (Uzbek), KY\r\n(Kyrgyz), TG (Tajik), TK (Turkmen), KK (Kazakh), UK (Ukrainian).\r\nDetermining the user’s language\r\nHowever, likely due to an error, this version of ransomware only encrypts files if the system language is Russian.\r\nIf we look closely at the conditions above, we can see that the first condition is ‘!=’ (‘not equal’). This makes the\r\nTrojan execute the code branch that exits without encryption on systems systems where the language is not\r\nRussian. If the condition was ‘==’, the other branch would have been taken, resulting in what was probably the\r\noriginally intended behavior of the Trojan.\r\nThe ransom note in this variant is implemented as an HTA file named \u003cID\u003e-DECRYPT.hta, where \u003cID\u003e is the\r\nunique victim ID assigned by the malware. The HTA file is launched upon completion of the file encryption and\r\nalso added to the autorun via registry:\r\nreg add HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun /v “zapiska” /d “C:UsersuserJSWRM-DECRYPT.hta”\r\nreg add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v “zapiska” /d “C:UsersuserJSWRM-DECRYPT.hta”\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 5 of 26\n\nRansom note of JSWorm 4.0.3\r\nCryptographic scheme\r\nThis version of JSWorm uses the WinAPI implementation of RSA and a custom implementation of AES to\r\nencrypt files. JSWorm generates two random values of 128 bits (IV) and 256 bits (key) that are limited to the\r\ncharacters: a…z, A…Z, and 0…9. The RSA public key is embedded inside the ransomware:\r\nRSA public key used in JSWorm 4.0.3\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 6 of 26\n\nUsing this key, JSWorm encrypts the AES key and initialization vector (IV) and encodes them into Base64:\r\nWinAPI RSA encryption in JSWorm 4.0.3\r\nAfterwards, this value is added to the ransomware note \u003cID\u003e-DECRYPT.hta, but the value itself is not displayed\r\nvisually because it is located inside the file as an HTML comment.\r\nValues inside the .hta ransom note file\r\nIn order to make decryption attempts more difficult for researchers, the malware developers implemented a\r\ncustom variant of the AES block cipher which is incompatible with the standard algorithm. The contents of the\r\nvictim’s files are encrypted by this cipher with the key and IV described above.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 7 of 26\n\nFor optimization, like before, only the first 160,000 bytes are encrypted in large files. After encryption, an\r\nadditional extension is appended to the filename, which is familiar to us from the previous sample: “\u003cfilename\u003e.\r\n[ID-NQH1J49][doctorSune@protonmail.com].JSWRM”.\r\nEncryption flaws\r\nIn this variant of JSWorm the developers tried to fix the flaws found by researchers in previous versions.\r\nHowever, decryption without payment was still possible. The pseudorandom number generator used to generate\r\nthe key and IV is not cryptographically secure and it allows researchers to restore the key and IV by attacking the\r\ngeneration algorithm. Knowing these values, they can decrypt the victims’ data.\r\nAugust 2019: Nemty 1.4\r\nMD5: 1780f3a86beceb242aa81afecf6d1c01\r\nThe code change between JSWorm and Nemty is significant. Based on our analysis, the malware developers may\r\nhave rewritten their Trojan from scratch, possibly to prevent successful decryption attempts that allowed victims\r\nof several earlier variants of JSWorm to restore their data without paying.\r\nThis sample is also developed in C++ and compiled in MS Visual Studio. It implements a minor anti-analysis trick\r\nconsisting of a string obfuscation algorithm. The strings (e.g., ransom note name and contents, RSA public key,\r\npayment URL, etc.) are encrypted by the RC4 stream cipher with a hardcoded key “fuckav” and encoded in\r\nBase64.\r\nRansom note of Nemty 1.4\r\nUpon launch, the sample will gather the information about storage devices attached to the infected machine, get its\r\nexternal IP address by an HTTP request to http://api.ipify.org, determine the victim’s country by requesting data\r\nfrom http://api.db-ip.com/v2/free/, generate a pair of RSA-2048 session encryption keys, and combine all the\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 8 of 26\n\ngathered information in a JSON structure. This structure is then encrypted by the public RSA key of the threat\r\nactors and saved at the end of the ransom notes as “NEMTY DECRYPTION KEY”.\r\nInformation gathered prior to being encrypted by RSA\r\nSome of the fields of interest in this structure:\r\nisRU: specifies whether the country of the victim determined by their external IP address is one of the\r\nfollowing: Russia, Belarus, Kazakhstan, Tajikistan, Ukraine\r\nversion: internal version of the Trojan\r\nCompID: unique ID of the infected machine\r\nFileID: infection ID generated on every malware launch\r\nUserID: ID of the affiliate, hardcoded in the Trojan sample\r\nkey: base64-encoded key for file encryption (will be discussed later)\r\npr_key: base64-encoded private session RSA-2048 key (will be discussed later)\r\nCryptographic scheme\r\nThe Trojan sample contains the threat actor’s hardcoded RSA-8192 public key, which we will call the master RSA\r\npublic key.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 9 of 26\n\nWhen executed on the victim’s machine, the Trojan also generates a pair of session RSA-2048 keys with the\r\nprivate key addressed above as pr_key. In addition to this, it also generates a 256-bit key that will be used with a\r\ncustom block cipher based on AES.\r\nThe 256-bit key and pr_key are encrypted by the master RSA public key and saved in the ransom notes.\r\nWhen encrypting each of the victim’s files, Nemty 1.4 will generate a 128-bit IV and use the 256-bit key with this\r\nIV to encrypt the file contents by a custom AES-based cipher. The IV is encrypted by the session public RSA key\r\nand appended to the encrypted file.\r\nEach encrypted file is renamed so that it gets an additional extension “._NEMTY_\u003c…\u003e_” where the skipped part\r\nis the infection ID mentioned above as FileID.\r\nEncryption flaws\r\nLike some of the earlier variants of JSWorm, the implementation of the cryptographic scheme in Nemty 1.4 is not\r\nflawless. Decryption of the victims’ files was possible by exploiting two weaknesses:\r\n1. 1 The PRNG for the key generation is not secure;\r\n2. 2 The RSA session key is not removed from the system store.\r\nBy using the first weakness, it’s possible to restore the 256-bit key, while the pr_key can be restored using the\r\nsecond. Once you know the pr_key, you can decrypt the IV and then, armed with the 256-bit key and IV, decrypt\r\nthe victim’s file contents.\r\nC\u0026C communication\r\nThe sample downloads the TOR client from https://dist.torproject.org/torbrowser/8.5.4/tor-win32-0.4.0.5.zip,\r\nextracts it and launches on the infected machine. After waiting for 30 seconds (obviously deemed by the malware\r\ndevelopers to be long enough to connect to the TOR network), the Trojan sends information about the infection to\r\nits C\u0026C server hardcoded in the sample:\r\nzjoxyw5mkacojk5ptn2iprkivg5clow72mjkyk5ttubzxprjjnwapkad.onion\r\nNemty 1.4 uses HTTP GET with URI /public/gate?data=\r\nThe information sent to the server is the same as that saved in each ransom note and is essentially an encrypted\r\nversion of the JSON structure discussed above.\r\nFurther versions of Nemty\r\nThe ‘Nemty’ branding was used until March of 2020. One of the last variants had the internal version 3.1.\r\nIn the few months following the initial creation, several intermediate versions of Nemty were discovered. The\r\nchanges include different mutex names and C\u0026C addresses, the added ability to terminate running processes, stop\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 10 of 26\n\nservices and delete shadow copies, improved cryptography that prevented unpaid decryption, changes to the\r\nransom text, and numerous tweaks.\r\nAs a side note, the developers of this malware tend to hardcode strings in Russian (transliterated) seemingly as a\r\njoke or maybe as a way to gain attention from researchers. Some of the strings contain profanities that turned out\r\nto be quotes from rap songs.\r\nStrings in a sample of Nemty 2.4\r\nStrings in a sample of Nemty 2.6\r\nMarch 2020: Nefilim\r\nMD5: 5ff20e2b723edb2d0fb27df4fc2c4468\r\nAround March 2020, the developers changed the branding of their Trojan to Nefilim. Around the time the first\r\nvariants of Nefilim started appearing, the distribution model of this family changed. The developers switched from\r\nthe public RaaS scheme used with the JSWorm and Nemty variants to private cooperation with affiliates aimed at\r\nbig-game hunting. The threat actors started targeting high-profile victims and manually operating inside the\r\nvictim’s network, exfiltrating confidential data and threatening to leak it to intimidate the victim.\r\nAll auxiliary functionality such as process termination, deletion of shadow copies, communication with C\u0026C, was\r\nremoved from the Trojan’s code. The Trojan became a single-purpose binary used exclusively for file encryption.\r\nIf any additional actions were deemed necessary, they were carried out by the threat actors manually or with the\r\nhelp of additional third-party tools.\r\nNefilim is developed in C++ and compiled in MS Visual Studio like Nemty, and the code overlap between the\r\nlater versions of Nemty (2+) and Nefilim is very substantial and allows us to suggest that the development\r\ncontinued from the same source code.\r\nOne example of the code overlap is that of the string decryption procedures – they are identical with the RC4 key\r\nbeing the only difference.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 11 of 26\n\nIdentical string decryption procedures. Left: Nemty 2.6 (141dbb1ff0368bd0359972fb5849832d); right: Nefilim\r\nThe overlap is not limited to string obfuscation – code fragments for various procedures match throughout the\r\nsamples, including the key generation and file encryption functions.\r\nCode similarity in file encryption procedures. Left: Nemty 2.6 (141dbb1ff0368bd0359972fb5849832d); right:\r\nNefilim\r\nUnlike Nemty, the Nefilim sample is signed by a digital signature that was valid at the time this malware variant\r\nwas being actively distributed, but has since been revoked.\r\nUpon launch, the malware checks command line arguments. If there are no arguments, it proceeds to search for\r\nthe victim’s files on all local and remote drives. If an argument is given, the Trojan checks whether it is an existing\r\ndirectory path. If so, it will encrypt the files in this directory. Otherwise, it will interpret the argument as a file path\r\nand attempt to encrypt this file. The command line argument checks may have been added to allow cybercriminals\r\nto manually choose files for encryption or merely as a debug functionality.\r\nCryptographic scheme\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 12 of 26\n\nThe Trojan body contains the threat actors’ hardcoded master RSA-2048 public key. When processing each\r\nvictim’s file, Nefilim generates a 128-bit key and a 128-bit IV and encrypts the file content by AES in CBC\r\nmode. The key and IV are encrypted by the RSA master key and saved at the end of the encrypted file.\r\nThe encrypted file is renamed so that it gets the additional extension .NEFILIM.\r\nThe ransom notes are saved as NEFILIM-DECRYPT.txt in the processed directories and contain email addresses\r\nto contact the extortionists.\r\nRansom note dropped by Nefilim\r\nApril 2020: Offwhite\r\nMD5: ad25b6af563156765025bf92c32df090\r\nWith the branding change from Nefilim to Offwhite the code of the malware has been further trimmed to reduce\r\nthe resulting binary size. To achieve this, the developers stopped using the STL library and got rid of C++ runtime\r\ncode that was adding unnecessary bulk. Otherwise, it’s still basically the same old Nefilim. In addition to the\r\ncapabilities we already discussed in the previous section, one other feature of note has been added to the Trojan\r\ncode allowing it to generate a wallpaper from the ransom text and save it as “scam.jpg”.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 13 of 26\n\nWallpaper generated by Offwhite\r\nJune 2020: Telegram\r\nMD5: 004f67c79b428da67938dadec0a1e1a4\r\nThe differences between the Offwhite and Telegram variants of the Trojan are minimal. The code is almost\r\nidentical with the main differences being the encrypted file extension (.TELEGRAM), the ransom note name\r\n(TELEGRAM-RECOVER.txt), and the fact that the names of imported API functions are not encoded as HEX\r\nstrings.\r\nNovember 2020: Fusion\r\nMD5: f37cebdff5de994383f34bcef4131cdf\r\nThis Trojan variant is written in the Go programming language. As we mentioned above, previous variants were\r\ndeveloped in C++, which means a complete rewrite from scratch, possibly by another developer.\r\nHowever, the similar overall modus operandi of the malware, similar cryptographic scheme, matching ransom\r\nnotes, and the fact that the binary is signed, suggest this sample is in fact a new variant of the JSWorm family.\r\nWhat’s more, the data leak site addresses hardcoded in the Trojan’s body are the same as the ones used\r\npreviously by these threat actors, which is a pretty compelling argument in support of our suggestion that there’s\r\na link between Fusion and its predecessors.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 14 of 26\n\nAlso, like the previous variants, the Fusion program accepts a command line argument: the name of the file to be\r\nencrypted (possibly used to debug the ransomware).\r\nCryptographic scheme\r\nThe program generates two 128-bit random numbers (IV and key) that are used to encrypt files using AES in\r\nGCM mode according to the following scheme: if the file is less than 1.5MB, then the entire file is encrypted; if\r\nthe file is larger, then sequentially:\r\n320KB of information is encrypted;\r\n320KB skipped (not encrypted);\r\nthe next 320KB are encrypted;\r\nthe next 320KB are skipped;\r\n…\r\nand so on until the end of the file.\r\nThis means that if the file is large, half turns out to be encrypted (albeit in alternating blocks).\r\nA master public RSA key is embedded inside the program and used to encrypt the IV and key values. Once\r\nencrypted, they are appended to the end of each encrypted file.\r\nRSA public key used by Fusion\r\nAnd finally, the line “FUSION” is written to the end of the file. The extension “.FUSION” is then appended to the\r\nfile name. The sample also leaves a note with contacts for communication (FUSION-README.txt):\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 15 of 26\n\nRansom note dropped by Fusion\r\nJanuary 2021: Milihpen\r\nMD5: e226e6ee60a4ad9fc8eec41da750dd66\r\nWith the Milihpen variant the actors behind the JSWorm family have once again completely reworked the code of\r\nthe malware, or perhaps hired another developer to implement it from scratch. This sample is once again\r\ndeveloped in C++ (like Nefilim and previous variants) and not Golang (like Fusion).\r\nDespite this, the main functionality, execution flow, crypto scheme and data leak site addresses are preserved. In\r\naddition, the Trojan name reveals a connection to one of the previous malware variants – it’s the word “Nephilim”\r\nwritten backwards.\r\nThe Trojan now logs all its actions to console, probably making it more convenient for the malware operator to\r\ncontrol the infection process.\r\nConsole logging of Milihpen\r\nAs with previous variants, the malware sample is signed by a digital certificate. Upon launch, Milihpen parses the\r\nconfiguration data hardcoded in the Trojan’s body. This configuration structure is stored in JSON format and\r\ncontains the following fields:\r\n1\r\n2\r\n3\r\n{\r\n//mutex name\r\n\"mutex\": \"MILIHPEN\",\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 16 of 26\n\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n//encrypted file extension\r\n\"ext\": \"MILIHPEN\",\r\n//ransom note name part\r\n\"nt_name\": \"-INSTRUCT.txt\",\r\n//master RSA public key (base64-encoded), redacted\r\n\"pub\": \"UlNB...Bnum9ew==\",\r\n//ransom note text (base64-encoded), redacted\r\n\"nt_content\": \"VHdvIHRoa...wuY29t\",\r\n//skipped file extensions\r\n\"whiteext\": [\".exe\", \".dll\", \".lnk\", \".url\", \".log\", \".cab\", \".cmd\", \".bat\", \".dll\", \".msi\", \".mp3\", \".mp4\",\r\n\".pif\", \".ini\"],\r\n//skipped directory names\r\n\"whitedir\": [\"windows\", \"programdata\", \"program files\", \"program files (x86)\", \"appdata\",\r\n\"$recycle.bin\", \"all users\", \".\", \"..\", \"rsa\"],\r\n//dynamically imported API function names\r\n\"winapi\": [\"MessageBoxA\", \"MessageBoxW\", \"BCryptOpenAlgorithmProvider\",\r\n\"BCryptGenRandom\", \"BCryptImportKeyPair\", \"BCryptEncrypt\"]\r\n}\r\nAfter parsing the values from the configuration, Milihpen creates a mutex, parses command line arguments and\r\nproceeds to operate with the same logic as Nefilim and more recent JSWorm variants. If a command line argument\r\nis provided, the Trojan checks whether it’s a directory path. If so, it will encrypt files inside it; otherwise, it will\r\ninterpret it as a file path and try to encrypt it. If no argument is given, the Trojan searches all local and remote\r\ndrives for the victim’s files.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 17 of 26\n\nConfiguration JSON structure in the Milihpen sample\r\nCryptographic scheme\r\nAs with other aspects, Milihpen closely mimics the high-level logic of previous variants starting with Nefilim and\r\nits successors. Code analysis shows, however, that the implementation has been completely rewritten.\r\nTo encrypt the files, Milihpen uses the same algorithms: AES in CBC mode and RSA. The AES key and IV are\r\nalso 128-bit and are saved after encryption by the master public RSA key at the end of the encrypted file.\r\nFor random number generation and RSA encryption, unlike its predecessors, Milihpen uses functions from BCrypt\r\nAPI which is a part of the Cryptography Next Generation (CNG) API that was introduced in Windows Vista. This\r\ndoesn’t provide any significant advantages to Milihpen, but it’s a notable characteristic as BCrypt API is not\r\ncommonly used in crypto-ransomware nowadays.\r\nThe encrypted files are renamed with an additional extension .MILIHPEN and the ransom notes are saved as\r\nMILIHPEN-INSTRUCT.txt.\r\nThe ransom note contains similar text to previous variants of this family as well as the same data leak site\r\naddresses.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 18 of 26\n\nRansom note dropped by Milihpen\r\nFebruary 2021: Gangbang\r\nMD5: 173ab5a59490ea2f66fe37c5e20e05b8\r\nThe Gangbang variant is identical to Milihpen and is currently the most recently discovered strain of this\r\nransomware family. The only notable difference is the fact that the configuration structure is now encrypted by\r\nAES with a hardcoded key and IV instead of being in plaintext like in Milihpen. Additionally, in contrast with\r\nprevious versions, the digital signature on this sample is invalid.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 19 of 26\n\nConfiguration of the Gangbang sample (redacted)\r\nData leak site\r\nIn the spring of 2020, the actors behind JSWorm family switched to big-game hunting and started their own\r\nwebsite where they could publish confidential data stolen from their victims.\r\nAt the time of writing, the website is still operational and contains posts about more than a hundred organizations\r\nthat fell victim to this malware.\r\nPage about the threat actors’ terms\r\nThe ‘contact’ page lists email addresses currently used by the threat actors for negotiations.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 20 of 26\n\nPage with contact email addresses\r\nFor some victims there are also individual pages where some of the data stolen from them can be downloaded.\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 21 of 26\n\nStolen data download page\r\nVictims\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 22 of 26\n\nBased on our KSN telemetry, we created a chart illustrating the geographical distribution of JSWorm ransomware\r\nattacks.\r\nGeography of JSWorm victims according to KSN (download)\r\nTop 10 countries attacked by JSWorm according to KSN statistics\r\nCountry %*\r\n1 China 21.39%\r\n2 United States of America 7.96%\r\n3 Vietnam 7.46%\r\n4 Mexico 6.97%\r\n5 Russian Federation 6.47%\r\n6 Brazil 5.47%\r\n7 India 5.47%\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 23 of 26\n\n8 Germany 4.98%\r\n9 France 4.48%\r\n10 Republic of Korea 2.99%\r\n* Unique users attacked by JSWorm ransomware family in the country as a percentage of all users who\r\nencountered JSWorm ransomware\r\nWe also analyzed the data about victims posted by the threat actors themselves on their data leak site. Based on\r\nthis data, we created a chart illustrating the distribution of JSWorm victims by industry.\r\nDistribution of JSWorm victims by industry according to the data leak site of the threat actors (download)\r\nAccording to the victim list published by the threat actors, two-fifths (41%) of JSWorm attacks were targeted\r\nagainst companies in the Engineering and Manufacturing category. Energy and Utilities (10%), Finance (10%),\r\nProfessional and Consumer Services (10%), Transportation (7%), and Healthcare (7%) were also at the top of\r\ntheir list.\r\nConclusion\r\nThe JSWorm family has already been evolving for two years and during this time it has changed distribution\r\nmodels and the Trojan has undergone several complete redevelopments. Since its initial emergence in 2019, it has\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 24 of 26\n\nturned from a typical mass-scale ransomware threat affecting mostly individual users into a typical big-game\r\nhunting ransomware threat attacking high-profile targets and demanding massive ransom payments.\r\nAs with other targeted ransomware threats of today, the key to preventing JSWorm infection incidents is a\r\ncomplex approach to securing an organization’s network. Any weakness may become an entry point for the threat\r\nactors, be it a vulnerable version of server-side software, an employee clicking a malicious link, a weak password\r\nfor remote control systems, and so on.\r\nTo boost defenses against big-game hunting ransomware, we recommend carrying out a security audit of your\r\nnetwork in order to find and proactively fix any security flaws.\r\nOther recommendations for maximizing security of your organization:\r\nDo not expose remote desktop services (such as RDP) to public networks unless absolutely necessary and\r\nalways use strong passwords for them.\r\nMake sure commercial VPN solutions and other server-side software are always up to date as exploitation\r\nof this type of software is a common infection vector for ransomware. Always keep client-side applications\r\nup to date as well.\r\nFocus your defense strategy on detecting lateral movements and data exfiltration to the internet. Pay\r\nspecial attention to the outgoing traffic to detect cybercriminal connections. Back up data regularly. Make\r\nsure you can quickly access it in an emergency when needed. Use the latest Threat Intelligence information\r\nto stay aware of actual TTPs used by threat actors.\r\nUse solutions like Kaspersky Endpoint Detection and Response and the Kaspersky Managed Detection and\r\nResponse service to help identify and stop an attack at the early stages, before the attackers achieve their\r\nultimate goals.\r\nTo protect the corporate environment, educate your employees. Dedicated training courses can help, such\r\nas those provided in the Kaspersky Automated Security Awareness Platform.\r\nUse a reliable endpoint security solution, such as Kaspersky Endpoint Security for Business that is\r\npowered by exploit prevention, behavior detection and a remediation engine that is able to roll back\r\nmalicious actions. KESB also has self-defense mechanisms that can prevent its removal by cybercriminals.\r\nIoC\r\nJSWorm (early variant)\r\nMD5: a20156344fc4832ecc1b914f7de1a922\r\nJSWorm 4.0.3\r\nMD5: 5444336139b1b9df54e390b73349a168\r\nNemty 1.4\r\nMD5: 1780f3a86beceb242aa81afecf6d1c01\r\nNefilim\r\nMD5: 5ff20e2b723edb2d0fb27df4fc2c4468\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 25 of 26\n\nOffwhite\r\nMD5: ad25b6af563156765025bf92c32df090\r\nTelegram\r\nMD5: 004f67c79b428da67938dadec0a1e1a4\r\nFusion\r\nMD5: f37cebdff5de994383f34bcef4131cdf\r\nMilihpen\r\nMD5: e226e6ee60a4ad9fc8eec41da750dd66\r\nGangbang\r\nMD5: 173ab5a59490ea2f66fe37c5e20e05b8\r\nSource: https://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nhttps://securelist.com/evolution-of-jsworm-ransomware/102428/\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/evolution-of-jsworm-ransomware/102428/"
	],
	"report_names": [
		"102428"
	],
	"threat_actors": [],
	"ts_created_at": 1775434203,
	"ts_updated_at": 1775826763,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a076df8388748fe4d11827addad3497ed334b915.pdf",
		"text": "https://archive.orkl.eu/a076df8388748fe4d11827addad3497ed334b915.txt",
		"img": "https://archive.orkl.eu/a076df8388748fe4d11827addad3497ed334b915.jpg"
	}
}