Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

Nemesis2024 Ransomware Decryption & Data Recovery

  • Active
  • Medium
  • No public decryptor

Nemesis2024 is a family 360 has listed repeatedly in its China ransomware reports since October 2024, under the search keyword 888 and named after a "Nemesis" field in its ransom note. Operators brute-force RDP and database passwords, then deploy it by hand. Public technical detail is scarce and there is no decryptor; a Dharma variant also ends in .888, so the two must be told apart.

First seen
2024-10
File extensions
.888
Ransom notes
No public information
Affected platforms
Windows / Databases

Public information on this family is limited. What follows is compiled from the small amount of verified material available, so please contact us for a sample assessment before you act on it.

Family profile

File extensions
  • .888
Ransom notes
No public information
Contact patterns
  • The ransom note carries a "Nemesis" family field, which 360 used to name it
  • No contact details or ransom amounts have been published; rely on the note found on site
Aliases / versions
888 勒索病毒、.888 勒索病毒(国内口径)、Nemesis 勒索病毒(勒索信字段)
First seen
2024-10
Status
Active
Operational status
Actively operating
Threat level
Medium
Affected platforms
  • Windows
  • Databases
Tags
  • Prevalent in China
  • Active
  • RDP brute force
  • Targets databases
Decryptor
No public decryptor

As of 2026-10-21 there is no free public decryptor for Nemesis2024. No More Ransom does not list it, and 360's monthly reports that name the family say nothing about decryption.

Some online sources claim 360 can decrypt Nemesis2024. We checked the original text of 360's April and May 2026 reports: the "decryption supported" statement there refers to the Wmansvcs (wman) family, not Nemesis2024. The Dharma variant that also ends in .888 has no public decryptor either, and Avast's Crypt888 decryptor targets an entirely different family and does not apply.

Sources

Overview

Nemesis2024 is a family named by a Chinese security vendor, with almost no matching public analysis abroad. The earliest record we can find is 360's October 2024 ransomware report, which lists the keyword 888 as active, stating that it "belongs to the Nemesis2024 family, named after the Nemesis family field in the ransom note", and recorded RDP password brute force followed by manual deployment as the way in. It has reappeared in 360's reports many times since; the April, May and July 2026 reports expand the method to "brute-forcing RDP and database passwords, then deploying by hand on success".

Information on this page is limited. 360's reports give only the keyword, the origin of the name and the spread method; no full ransom note, filename pattern, algorithm or sample hash has been published. The identification and response advice below rests on those facts and on our experience with similar hand-deployed families, not on confirmed technical detail about this one. We will update this page as reporting matures.

Do not confuse it with two lookalikes.

  • An older family also called Nemesis appeared around 2017; it is not the family 360 calls Nemesis2024.
  • The Dharma family has a variant ending in .888, with filenames such as sample.jpg.id-1E857D00.[donald888@mail.fr].888 and a FILES ENCRYPTED.txt note on the desktop. When you see .888, check whether the filename carries an id code and an email address before deciding which family you have.

How to identify it

Extension. 360's search keyword is 888, and cases reported in China generally end in .888, but the full filename pattern has not been published.

Ransom note. It contains a Nemesis field, which is what 360 named the family after; the filename and contact details must be taken from the note on site.

Telling it apart from Dharma .888. The Dharma variant's filenames contain, in order, id- plus an eight-character code, an email address in square brackets and then .888, with FILES ENCRYPTED.txt on the desktop and a pop-up window. If the filenames lack those elements and the note mentions Nemesis, Nemesis2024 is the likelier match.

Intrusion traces. Because it is deployed by hand after brute force, the Windows security log usually shows a burst of failed RDP logons (event ID 4625) followed by a success (4624), and database logs show dense runs of failed logins.

Advice. Keep three to five encrypted files and the original note for expert comparison; do not decide on the extension alone.

Infection vectors

According to 360, Nemesis2024 spreads mainly by brute-forcing RDP and database passwords, then deploying by hand on success. In practice:

  • The way in is usually RDP exposed directly to the internet (port 3389 or a changed port) and database ports such as SQL Server or MySQL.
  • Once logged in, the operators work by hand - typically switching off antivirus and looking for databases and backups before choosing when to deploy.
  • Where the same credentials are reused across internal servers, the operators log into them one after another.

Public reporting does not say whether it spreads automatically, so investigate on the assumption that a human operator may have logged into several machines.

Encryption behavior

There is no public analysis of Nemesis2024's algorithm, whether it encrypts whole files, or whether it deletes shadow copies.

Those three facts decide the recovery route. If shadow copies survive, Previous Versions may bring some files straight back; if encryption is partial, database files may keep many intact pages and allow structural repair; if whole files are encrypted and shadow copies are gone, backups are the only route. The first step is therefore to measure it on real samples rather than borrowing conclusions from other families.

Assess before you act

Recoverability assessment

We do not pay ransoms and do not negotiate; our work is technical recovery and forensics. Recovery from Nemesis2024 is assessed in this order:

1) Public decryptor: none.

2) Shadow copies. Check on a read-only image whether they survived.

3) Structural database repair. If SQL Server mdf/ldf, MySQL ibd and similar files prove to be partially encrypted, page-level extraction and rebuilds can be attempted.

4) Backups and snapshots. Offline and offsite backups, storage and hypervisor snapshots, and the automatic backup folders of finance and ERP software. Hands-on operators often look for backups first, so confirm they were not encrypted or deleted before restoring.

5) Unencrypted copies and logs. Read replicas, transaction logs and business documents held by upstream and downstream systems.

The achievable ratio depends on what we measure; we give an assessment first, then fix the scope, and never promise "100% recovery".

Our response plan

Hit by Nemesis2024 ransomware? What to do

  1. Containment and evidence preservation

    Disconnect affected servers, close internet-exposed RDP and database ports, and change every credential that may have leaked. Do not reboot or reinstall. Take read-only images of affected volumes, export the Windows security log and database login logs, and keep encrypted files plus the original note.

  2. Family confirmation and sample testing

    Compare the Nemesis field in the note and the filename pattern to rule out Dharma .888 and other same-extension families; then test on copies whether whole files were encrypted and whether shadow copies were deleted, and choose the recovery route accordingly.

  3. Recoverability assessment and execution

    Inventory shadow copies, backups, snapshots and replicas, run sample repairs on critical databases, deliver a written assessment, then restore on images with integrity checks and business verification after each batch.

  4. Root cause and hardening

    Use login logs to reconstruct the brute-force sources and the time and account of each successful logon, and check for new accounts and scheduled tasks. Hardening: keep RDP and databases off the internet behind VPN or a jump host; strong passwords plus account lockout; no remote logins for default accounts such as sa; no password reuse across servers; offline backups.

Risk warning

What not to do

  • Do not decide on the .888 extension alone - Dharma also has a .888 variant, and the response differs.
  • Do not believe claims that 360 can decrypt Nemesis2024; the decryption statement in its reports refers to the Wmansvcs family.
  • Do not reboot, reinstall or write heavily to affected disks; that destroys shadow copies and residual database data.
  • Do not restore service before changing passwords and closing internet-facing ports - the operators' credentials still work.
  • Do not contact the operators or pay on your own.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

Similar families

FAQ

Nemesis2024 Frequently asked questions

  • Files now end in .888 - what ransomware is this?

    In China, 360 attributes most .888 cases to the Nemesis2024 family, named after a Nemesis field in its note and spread by brute-forcing RDP and database passwords before manual deployment. The Dharma family, however, also has a .888 variant, with filenames like name.id-XXXXXXXX.[email].888 and a FILES ENCRYPTED.txt on the desktop. Check whether the filename carries an id code and an email, and whether the note mentions Nemesis, before deciding.

  • Can Nemesis2024 be decrypted?

    There is no public decryptor today. Claims that 360 can decrypt it come from a statement in 360's reports that actually refers to the Wmansvcs family. The first step is to test the samples - whether shadow copies survive and whether whole files are encrypted - and then choose between shadow-copy recovery, structural database repair or restoring from backups.

  • We changed the RDP port and still got hit - why?

    Changing the port only stops the crudest scans; attackers' scanners sweep common high ports too, and as long as the port is internet-facing with a weak password, brute force will eventually succeed. 360 also records database brute force, not just RDP. What works is keeping RDP and database ports off the internet behind VPN or a jump host, with strong passwords, account lockout and alerts on failed logins.