Over the past few years, the ransomware menace landscape has been gradually varying. We have been witness to a paradigm change. From the massive outbreaks of 2017, such as WannaCry, NotPetya, and Bad Rabbit, a lot of ransomware actors have moved to the covert but very profitable tactic of “big-game hunting”. News of ransomware causing an outage of some global corporation’s services has now become commonplace.

In some suits, this global trend is just a reflection of the continuous life cycle of threats: age-old ransomware households shut down and new ones seem and prosecute new targets. Nonetheless, there are times when a single ransomware household has evolved from a mass-scale operation to a highly targeted threat- all in the span of two years. In this post we want to talk about one of those households, named JSWorm.


JSWorm ransomware was discovered in 2019 and since then different variants have gained notoriety under various epithets such as Nemty, Nefilim, Offwhite and several others.

Several versions were released as part of each ” rebranded ” variant that varied different aspects of the code, renamed file extensions, cryptographic schemes and encryption keys.

In the diagram below we present some of the names used by this Trojan along with the dates the matching variant was actively released during the month of the wild( ITW)( not the date it was first encountered ). We should note that this list is not comprehensive, but it celebrates the main milestones in the evolution of JSWorm.

Together with epithet changes, the developers of this ransomware has always been reworking their code and trying different approaches to distribution.

At some level in 2020 the developers even changed the programming language from C ++ to Golang, completely rewriting the code from scratch. However, the similarity in the cryptographic scheme, ransom notes and use of the same data leak website address produced us to believe it’s the same campaign.

The original version of the malware, as well as some of the subsequent “rebrandings”, e.g ., Nemty, were advertised on an underground meeting by a poster with the username jsworm.

Forum advertisement for an early JSWorm variant

Distribution methods

From its creation in 2019 until the first six months of 2020, JSWorm was offered as a public RaaS and was observed propagating via 😛 TAGEND

RIG exploit kit Trik botnet Fake payment websites Spam campaigns

From the first six months of 2020, the public RaaS was closed and the operators be changed to big-game hunting. There is evidence of an initial transgres via exploitation of vulnerable server-side software( Citrix ADC) and unsecure RDP access.

Technical details

We will describe some notable variants of the JSWorm family encountered during the history of this malware. We won’t attempt to cover all the discovered variants of this malware as they are too numerous. The dates indicate the approximate interval when the corresponding variant was observed ITW.

May 2019: JSWorm

MD5: a2 0156344 fc4832ecc1b914f7de1a922

This sample is one of the earliest discovered variants of JSWorm ransomware and, unlike its successors, it doesn’t contain an internal version number. The sample is developed in C ++ and compiled in MS Visual Studio.

Besides file encryption, it performs actions such as stopping a number of running processes and services to maximize the number of files available for encryption. In addition, it deletes all system backups, shadow facsimiles, disables the system recuperation mode, and clears event logs.

Cryptographic scheme

The files are encrypted employing a custom modification of a Blowfish cipher with a 256 -bit key. The key is generated at the beginning of the program execution and based on concatenation of the strings: user name, device MAC address and volume serial number( example values in the comments ).

Key generation process

Then a string referred to by the ransom notes as” JSWORM PUBLIC KEY” is generated. In fact, asymmetric cryptography is not used here and using the word ” public” builds no sense in this context. What the ransomware developer is calling” JSWORM PUBLIC KEY” is in fact the aforementioned Blowfish key XOR-ed with the string “KCQKCQKCQKCQ” and encoded in Base6 4.

XOR with the “KCQKCQKCQKCQ” key

Below is an example of key calculation, with the serial number and MAC address values selected for illustration purposes 😛 TAGEND

Blowfish key: “53385773534FE:ED:00:DE:AF:00user” Public key after XOR: “5xpi~tfxvb\x05\x14q\x06\x15qsaq\x07\x14q\x02\x17qsa>049” Public key after conversion to Base6 4: “NXhwaX50Znh2Yn8FFHEGFXFzYXEHFHECF3FzYT4wNDk=”

A custom version of Blowfish is used for encryption of the content of each of the victim’s files. No more than 100,000 bytes are encrypted, probably to speed up encryption of large files. The encrypted data is written over the original.

The developers changed the internal implementing the Blowfish cipher, which resulted in it being incompatible with standard implementations, probably in an attempt to induce decryption more difficult for researchers.

After encrypting the contents of a file, the program renames it. An additional expansion “.[ ID- …][ mail @domain. tld ]. JSWORM” is added to the filename.

Encryption flaws

The malware essentially saves the key that can be used for decryption in the ransom notes. Base6 4-decoding and un-xoring it is trivial, and the victim’s data can be saved without paying the ransom. Even if the ransom note is for some reason lost, the key can be easily regenerated on the infected machine.

July 2019: JSWorm 4.0.3

MD5: 5444336139b1b9df54e390b73349a168

An improved and updated version of JSWorm that attempts to fix flaws found in the previous variants.

This sample contains a language check of the infected machine. This is most likely intended to prevent encryption of data on systems where the following languages are use: RU( Russian ), BE( Belarusian ), UZ( Uzbek ), KY( Kyrgyz ), TG( Tajik ), TK( Turkmen ), KK( Kazakh ), UK( Ukrainian ).

Determining the user’s language

However, likely due to an error, this version of ransomware only encrypts files if the system language is Russian. If we look closely at the conditions above, we can see that the first circumstance is ‘!=’ (‘ not equal ‘). This constructs the Trojan execute the code branch that exits without encryption on systems systems where the language is not Russian. If the condition was ‘==’, the other branch would have been taken, ensuing in what was probably the originally intended behavior of the Trojan.

The ransom note in this variant is implemented as an HTA file named -DECRYPT.hta, where is the unique victim ID assigned by the malware. The HTA file is launched upon completion of the file encryption and likewise added to the autorun via registry 😛 TAGEND

reg add HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run/ v “zapiska”/ d “C:\Users\user\JSWRM-DECRYPT.hta” reg add HKCU \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run/ v “zapiska”/ d “C:\Users\user\JSWRM-DECRYPT.hta”

Ransom note of JSWorm 4.0.3

Cryptographic scheme

This version of JSWorm uses the WinAPI implementation of RSA and a tradition implementation of AES to encrypt files. JSWorm produces two random values of 128 bits( IV) and 256 bits( key) that are limited to the characters: a…z, A…Z, and 0…9. The RSA public key is embedded inside the ransomware 😛 TAGEND

RSA public key used in JSWorm 4.0.3

Using this key, JSWorm encrypts the AES key and initialization vector( IV) and encodes them into Base6 4 😛 TAGEND

WinAPI RSA encryption in JSWorm 4.0.3

Afterwards, this value is added to the ransomware note -DECRYPT.hta, but the value itself is not displayed visually because it is located inside the file as an HTML comment.

Values inside the. hta ransom note file

In order to build decryption endeavors more difficult for researchers, the malware developers implemented a custom variant of the AES block cipher which is incompatible with the standard algorithm. The contents of the victim’s files are encrypted by this cipher with the key and IV described above.

For optimization, like before, merely the first 160,000 bytes are encrypted in large-scale files. After encryption, an additional extension is appended to the filename, which is familiar to us from the previous sample: “< filename >.[ ID-NQH1J 49 ][ doctorSune @protonmail. com ]. JSWRM “.

Encryption flaws

In this variant of JSWorm the developers tried to fix the flaws help find researchers in previous versions. However, decryption without pay was still possible. The pseudorandom number generator used to generate the key and IV is not cryptographically secure and it allows researchers to restore the key and IV by attacking the generation algorithm. Knowing these values, they can decrypt the victims’ data.

August 2019: Nemty 1.4

MD5: 1780f3a86beceb242aa81afecf6d1c01

The code change between JSWorm and Nemty is significant. Based on our analysis, the malware developers may have rewritten their Trojan from scratch, maybe to prevent successful decryption attempts that allowed the number of victims of several earlier variants of JSWorm to restore their data without paying.

This sample is also was produced in C ++ and compiled in MS Visual Studio. It implements a minor anti-analysis trick consisting of a string obfuscation algorithm. The strings( e.g ., ransom note epithet and contents, RSA public key, pay URL, etc .) are encrypted by the RC4 stream cipher with a hardcoded key “fuckav” and encoded in Base6 4.

Ransom note of Nemty 1.4

Upon launch, the sample will amass the information about memory device attached to the infected machine, get its external IP address by an HTTP request to http ://, determine the victim’s country by request data from http :// v2/ free /, generate a pair of RS-A2 048 session encryption keys, and combining all the gathered information in a JSON structure. This structure is then encrypted by the public RSA key of the threat performers and saved at the end of the ransom notes as” NEMTY DECRYPTION KEY “.

Information met prior to being encrypted by RSA

Some of the fields of interest in this structure 😛 TAGEND

isRU: specifies whether the country of the victim determined by their external IP address is one of the following: Russia, Belarus, Kazakhstan, Tajikistan, Ukraine version: internal version of the Trojan CompID: unique ID of the infected machine FileID: infection ID made on every malware launching UserID: ID of the affiliate, hardcoded in the Trojan sample key: base6 4-encoded key for file encryption( will be discussed later) pr_key: base6 4-encoded private conference RS-A2 048 key( will be discussed later)

Cryptographic scheme

The Trojan sample contains the threat actor’s hardcoded RS-A8 192 public key, which we will call the master RSA public key.

When executed on the victim’s machine, the Trojan likewise makes a pair of session RS-A2 048 keys with the private key addressed above as pr_key. In addition to this, it also makes a 256 -bit key that will be used with a custom block cipher based on AES.

The 256 -bit key and pr_key are encrypted by the master RSA public key and saved in the ransom notes.

When encrypting each of the victim’s files, Nemty 1.4 will generate a 128 -bit IV and use the 256 -bit key with this IV to encrypt the file contents by a tradition AES-based cipher. The IV is encrypted by the session public RSA key and appended to the encrypted file.

Each encrypted file is renamed so that it gets an additional extension “. _NEMTY_ <...> _” where the skipped proportion is the infection ID mentioned above as FileID.

Encryption flaws

Like some of the earlier variants of JSWorm, the implementation of the cryptographic strategy in Nemty 1.4 is not flawless. Decryption of the victims’ files was possible by exploit two lacks 😛 TAGEND

The PRNG for the key generation is not secure; The RSA session key is not removed from the system store.

By using the first weakness, it’s possible to restore the 256 -bit key, while the pr_key can be restored employing the second largest. Once you know the pr_key, you can decrypt the IV and then, armed with the 256 -bit key and IV, decrypt the victim’s file contents.

C&C communication

The sample downloads the TOR client from https :// torbrowser /8. 5.4/ tor-win3 2-0. 4.0.5. zip, extracts it and launches on the infected machine. After just wait 30 seconds( patently deemed by the malware developers to be long enough to connect to the TOR network ), the Trojan sends information about the infection to its C& C server hardcoded in the sample 😛 TAGENDzjoxyw5mkacojk 5ptn2iprkivg5clow72mjkyk5ttubzxprjjnwapkad. onion

Nemty 1.4 uses HTTP GET with URI/ public/ gate? data=

The knowledge sent to the server is the same as that saved in each ransom note and is essentially an encrypted version of the JSON structure discussed above.

Further different versions of Nemty

The’ Nemty’ branding was used until March of 2020. One of the last variants had the internal version 3.1.

In the few months following the initial initiation, several intermediate versions of Nemty were discovered. The changes include different mutex names and C& C address, the added ability to terminate running processes, stop services and delete shadow photocopies, improved cryptography that prevented unpaid decryption, changes to the ransom text, and numerous tweaks.

As a side note, the developers of this malware tend to hardcode strings in Russian( transliterated) seemingly as a joke or maybe as a behavior to gain attention from researchers. Some of the strings contain profanities that proving to be quotes from rap songs.

Strings in a sample of Nemty 2.4

Strings in a sample of Nemty 2.6

March 2020: Nefilim

MD5: 5ff20e2b723edb2d0fb27df4fc2c4468

Around March 2020, the developers varied the branding of their Trojan to Nefilim. Around the time the first variants of Nefilim started showing, the distribution framework of this family changed. The developers switched from the public RaaS scheme used with the JSWorm and Nemty variants to private cooperation with affiliates aimed at providing big-game hunting. The threat performers started targeting high-profile victims and manually operating inside the victim’s network, exfiltrating confidential data and threatening to leak it to frighten the victim.

All auxiliary functionality such as process termination, omission of darknes prints, communication with C& C, was removed from the Trojan’s code. The Trojan became a single-purpose binary used exclusively for file encryption. If any additional acts were considered necessary, they were carried out by the threat performers manually or with the help of additional third-party tools.

Nefilim is developed in C ++ and compiled in MS Visual Studio like Nemty, and the code overlap between the later versions of Nemty( 2+) and Nefilim is very substantial and allows us to suggest that the growth continued from the same source code.

One example of the code overlap is the question of the string decryption procedures- they are identical with the RC4 key being the only difference.

Identical string decryption procedures. Left: Nemty 2.6( 141dbb1ff0368bd0359972fb5849832d ); right: Nefilim

The overlap is not limited to string obfuscation- code fragments for various procedures match in all regions of the samples, including the key generation and file encryption functions.

Code similarity in file encryption procedures. Left: Nemty 2.6( 141 dbb1ff 0368 bd0359972fb5849832d ); right: Nefilim

Unlike Nemty, the Nefilim sample is signed by a digital signature that was valid at the time this malware variant was being actively distributed, but has all along been been revoked.

Upon launch, the malware checks command line statements. If there is a lack of statements, it proceeds to search for the victim’s files on all local and remote drives. If an arguing is given, the Trojan checks whether it is an existing directory path. If so, it will encrypt the files in this directory. Otherwise, it will construe the controversy as a file route and attempt to encrypt this file. The command line argument checks may have been added to allow cybercriminals to manually choose files for encryption or simply as a debug functionality.

Cryptographic scheme

The Trojan body contains the threat performers’ hardcoded lord RS-A2 048 public key. When processing each victim’s file, Nefilim generates a 128 -bit key and a 128 -bit IV and encrypts the file content by AES in CBC mode. The key and IV are encrypted by the RSA master key and saved following the adjournment of the encrypted file.

The encrypted file is renamed so that it gets the additional expansion. NEFILIM.

The ransom notes are saved as NEFILIM-DECRYPT.txt in the processed directories and contain email addresses to contact the extortionists.

Ransom note dropped by Nefilim

April 2020: Offwhite

MD5: ad2 5b6af563156765025bf92c32df090

With the branding modification from Nefilim to Offwhite the code of the malware has been further trimmed to reduce the resulting binary size. To achieve this, the developers stopped applying the STL library and got rid of C ++ runtime code that was adding unnecessary majority. Otherwise, it’s still basically the same age-old Nefilim. In addition to the capabilities we already discussed in the previous section, one other feature of note has been added to the Trojan code allowing it to generate a wallpaper from the ransom text and save it as “scam.jpg”.

Wallpaper generated by Offwhite

June 2020: Telegram

MD5: 004f67c79b428da67938dadec0a1e1a4

The differences between the Offwhite and Telegram variants of the Trojan are minimal. The code is essentially the same with the main differences being the encrypted file expansion (. TELEGRAM ), the ransom note name( TELEGRAM-RECOVER.txt ), and the fact that the names of imported API functions are not encoded as HEX strings.

November 2020: Fusion

MD5: f3 7cebdff5de994383f34bcef4131cdf

This Trojan variant is written in the Go programming language. As we already mentioned, previous variants were developed in C ++, which means a complete rewrite from scratch, maybe by another developer.

However, the similar overall modus operandi of the malware, similar cryptographic scheme, matching ransom notes, and the fact that the binary is signed, indicate this sample is in fact a new variant of the JSWorm family.

What’s more, the data leak site address hardcoded in the Trojan’s body are the same as the ones use previously by these threat actors, which is a fairly obliging statement in support of our suggestion that there’s a link between Fusion and its predecessors.

Also, like the previous variants, the Fusion program accepts a command line debate: the name of the file to be encrypted( perhaps used to debug the ransomware ).

Cryptographic scheme

The program generates two 128 -bit random numbers( IV and key) that are used to encrypt files using AES in GCM mode according to the following scheme: if the file is lower than 1.5 MB, then the entire file is encrypted; if the file is larger, then sequentially 😛 TAGEND

320 KB of information is encrypted; 320KB hop-skip( not encrypted ); the next 320KB are encrypted; the next 320KB are hop-skip; … and so on until the end of the file.

This means that if the file is large, half turns out to be encrypted( albeit in alternating blocks ).

A master public RSA key is embedded inside the program and used to encrypt the IV and key values. Once encrypted, they are appended to the end of each encrypted file.

RSA public key used by Fusion

And ultimately, the line ” FUSION ” is written to the end of the file. The extension “. FUSION” is then appended to the file name. The sample also leaves a note with contacts for communication( FUSION-README.txt ):

Ransom note has decreased by Fusion

January 2021: Milihpen

MD5: e2 26 e6ee60a4ad9fc8eec41da750dd66

With the Milihpen variant the actors behind the JSWorm family have once again totally reworked the code of the malware, or perhaps hired another developer to implement it from scratch. This sample is once again developed in C ++( like Nefilim and previous variants) and not Golang( like Fusion ).

Despite this, the main functionality, execution flowing, crypto strategy and data leak site addresses are saved. In addition, the Trojan name reveals a connection to one of the previous malware variants – it’s the word “Nephilim” written backwards.

The Trojan now logs all its actions to console, probably constructing it more convenient for the malware operator to control the infection process.

Console logging of Milihpen

As with previous variants, the malware sample is signed by a digital certification. Upon launch, Milihpen parses the configuration data hardcoded in the Trojan’s torso. This configuration arrangement is stored in JSON format and contains these fields 😛 TAGEND

// mutex epithet

“mutex”: “MILIHPEN”,

// encrypted file expansion

“ext”: “MILIHPEN”,

// ransom note name part

“nt_name”: “-INSTRUCT.txt”,

// master RSA public key( base6 4-encoded ), redacted

“pub”: “UlNB…Bnum9ew == “,

// ransom note text( base6 4-encoded ), redacted

“nt_content”: “VHdvIHRoa…wuY2 9t”,

// hop-skip file expansions

“whiteext”:[ “.exe”, “.dll”, “.lnk”, “.url”, “.log”, “.cab”, “.cmd”, “.bat”, “.dll”, “.msi”, “.mp3”, “.mp4”, “.pif”, “.ini” ],

// skipped directory names

“whitedir”:[ “windows”, “programdata”, “program files”, “program files( x86) “, “appdata”, “$ recycle.bin”, “all users”, “.”, “..”, “rsa” ],

// dynamically imported API function epithets

“winapi”:[ “MessageBoxA”, “MessageBoxW”, “BCryptOpenAlgorithmProvider”, “BCryptGenRandom”, “BCryptImportKeyPair”, “BCryptEncrypt”]

After parsing the values from the configuration, Milihpen makes a mutex, parses command line contentions and proceeds to operate with the same logic as Nefilim and more recent JSWorm variants. If a command line contention is provided, the Trojan checks whether it’s a directory path. If so, it will encrypt files inside it; otherwise, it will construe it as a file path and try to encrypt it. If no controversy is given, the Trojan searches all local and remote drives for the victim’s files.

Configuration JSON structure in the Milihpen sample

Cryptographic scheme

As with other aspects, Milihpen closely simulates the high-level logic of previous variants starting with Nefilim and its successors. Code analysis indicates, however, that the implementation has been completely rewritten.

To encrypt the files, Milihpen uses the same algorithms: AES in CBC mode and RSA. The AES key and IV are also 128 -bit and are saved after encryption by the master public RSA key following the adjournment of the encrypted file.

For random number generation and RSA encryption, unlike its predecessors, Milihpen utilizes roles from BCrypt API which is a part of the Cryptography Next Generation( CNG) API that was introduced in Windows Vista. This doesn’t furnish any significant advantages to Milihpen, but it’s a notable characteristic as Bcrypt API is not commonly used in crypto-ransomware nowadays.

The encrypted files are renamed with an additional extension. MILIHPEN and the ransom notes are saved as MILIHPEN-INSTRUCT.txt.

The ransom note contains similar text to previous variants of this family as well as the same data leakage site addresses.

Ransom note dropped by Milihpen

February 2021: Gangbang

MD5: 173ab5a59490ea2f66fe37c5e20e05b8

The Gangbang variant is identical to Milihpen and is currently the most recently discovered strain of this ransomware household. The only notable difference is the fact that the configuration arrangement is now encrypted by AES with a hardcoded key and IV instead of being in plaintext like in Milihpen. Additionally, in contrast with previous versions, the digital signature on this sample is invalid.

Configuration of the Gangbang sample( redacted)

Data leakage website

In the spring of 2020, the actors behind JSWorm household be changed to big-game hunting and started their own website where they could publish confidential data stolen from their victims.

At the time of writing, the website is still operational and contains posts about more than a hundred organizations that have become victims to this malware.

Page about security threats performers’ terms

The’ contact’ page lists mailing address currently used by the threat actors for negotiations.

Page with contact email addresses

For some victims there are also individual pages where some of the data stolen from them is likely to be downloaded.

Stolen data download page


Based on our KSN telemetry, “weve created” a map exemplifying the geographical distribution of JSWorm ransomware attacks.

! part( e, i, n, s ) var t= “InfogramEmbeds”, d= e.getElementsByTagName( “script” )[ 0 ]; if( window[ t ]&& window[ t ]. initialized) window[ t ]. process && window[ t ]. process (); else if (! e.getElementById( n )) var o= e.createElement( “script” ); o.async= 1, n, o.src= “https :// js/ dist/ embed-loader-min.js”, d.parentNode.insertBefore( o, d )( record, 0, “infogram-async” );

Geography of JSWorm victims according to KSN( download)

Top 10 countries attacked by JSWorm according to KSN statistics

Country %* 1 China 21.39%

2 United Government of America 7.96% 3 Vietnam 7.46%

4 Mexico 6.97%

5 Russian Federation 6.47% 6 Brazil 5.47%

7 India 5.47%

8 Germany 4.98%

9 France 4.48%

10 Republic of Korea 2.99%

* Unique consumers assaulted by JSWorm ransomware family in the country as a percentage of all users who encountered JSWorm ransomware

We also analyzed the data about victims posted by the threat performers themselves on their data leak site. Based on this data, we created a map exemplifying the distribution of JSWorm victims by industry.

! function( e, i, n, s ) var t= “InfogramEmbeds”, d= e.getElementsByTagName( “script” )[ 0 ]; if( window[ t ]&& window[ t ]. initialized) window[ t ]. process && window[ t ]. process (); else if (! e.getElementById( n )) var o= e.createElement( “script” ); o.async= 1, n, o.src= “https :// js/ dist/ embed-loader-min.js”, d.parentNode.insertBefore( o, d )( document, 0, “infogram-async” );

Distribution of JSWorm victims by industry according to the data leak site of the threat actors( download)

According to the victim list published by the threat performers, two-fifths( 41%) of JSWorm assaults were targeted against corporations in the Engineering and Manufacturing category. Energy and Utilities( 10% ), Finance( 10% ), Professional and Consumer Service( 10% ), Transportation( 7 %), and Healthcare( 7 %) were also at the top of their list.


The JSWorm family has already been evolving for two years and during this time it has changed distribution models and the Trojan has undergone several complete redevelopments. Since its initial emergence in 2019, it has turned from a typical mass-scale ransomware threat affecting mostly individual users into a typical big-game hunting ransomware threat attacking high-profile the objective and demanding massive ransom payments.

As with other targeted ransomware threats of today, the key to preventing JSWorm infection incidents is a complex approach to procuring an organization’s network. Any weakness may become an entry point for security threats actors, be it a vulnerable version of server-side software, an employee clicking a malicious connect, a weak password for remote control systems, and so on.

To boost defenses against big-game hunting ransomware, we recommend carrying out a security examination of your network in order to find and proactively fix any security flaws.

Other recommendations for maximizing security of your organization 😛 TAGEND

Do not disclose remote desktop services( such as RDP) to public networks unless absolutely necessary and ever use strong passwords for them. Make sure commercial VPN solutions and other server-side software are always up to date as exploitation of this type of software is a common infection vector for ransomware. Ever keep client-side applications up to date as well. Focus your defense strategy on detect lateral movements and data exfiltration to the internet. Pay special attention to the outgoing traffic to detect cybercriminal linkages. Back up data regularly. Make sure you can quickly access it in an emergency when needed. Use the latest Threat Intelligence information to stay aware of actual TTPs used by threat performers. Employ solutions like Kaspersky Endpoint Detection and Response and the Kaspersky Managed Detection and Response service to help identify and stop an attack at the very early stages, before the attackers achieve their ultimate goals. To protect the corporate environment, educate individual employees. Dedicated training courses can help, such as those provided in the Kaspersky Automated Security Awareness Platform. Apply a reliable endpoint security solution, such as Kaspersky Endpoint Security for Business that is powered by exploit prevention, behavior detection and a remediation engine that is able to roll back malicious actions. KESB also has self-defense mechanisms that can prevent its removal by cybercriminals.


JSWorm( early variant) MD5: a2 0156344 fc4832ecc1b914f7de1a922

JSWorm 4.0.3 MD5: 5444336139b1b9df54e390b73349a168

Nemty 1.4 MD5: 1780f3a86beceb242aa81afecf6d1c01

Nefilim MD5: 5ff20e2b723edb2d0fb27df4fc2c4468

Offwhite MD5: ad2 5b6af563156765025bf92c32df090

Telegram MD5: 004f67c79b428da67938dadec0a1e1a4

Fusion MD5: f3 7cebdff5de994383f34bcef4131cdf

Milihpen MD5: e2 26 e6ee60a4ad9fc8eec41da750dd66

Gangbang MD5: 173ab5a59490ea2f66fe37c5e20e05b8

Read more: