Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

BeijingCrypt Ransomware Decryption & Data Recovery

  • Active
  • High
  • No public decryptor

BeijingCrypt takes its name from the .beijing extension used by early builds. It is a persistently prevalent family in China, deployed by hand after brute-forcing remote desktop or database credentials, and has cycled through .beijing, .360, .520, .halo and .bixi variants. No public decryptor exists.

First seen
2020-06
File extensions
.beijing .360 .520
Ransom notes
!RECOVER.txt
Affected platforms
Windows / Databases

Family profile

File extensions
  • .beijing
  • .360
  • .520
  • .genesis
  • .file
  • .fc
  • .montana
  • .halo
  • .bixi
  • .baxia
Ransom notes
  • !RECOVER.txt
  • !HELP!.txt
Contact patterns
  • Disposable mailboxes (free encrypted-mail domains, a primary and a backup address)
  • Telegram or another IM account as a fallback in some variants
Aliases / versions
Beijing 勒索病毒、.360 勒索病毒、Halo 变种、Bixi 变种、Baxia 变种
First seen
2020-06
Status
Active
Threat level
High
Affected platforms
  • Windows
  • Databases
Tags
  • Prevalent in China
  • RDP brute force
  • Targets databases
  • Active
Decryptor
No public decryptor

BeijingCrypt uses hybrid AES-256 and RSA-2048 encryption, with each host's symmetric key protected by an RSA private key held by the attacker. No public free decryptor exists, and there is no entry for it in No More Ransom or vendor decryptor libraries.

One warning is worth repeating: the family's use of a .360 extension deliberately borrows the name of a well-known Chinese security vendor to confuse victims and has no connection to that company. "Dedicated .360 decryptors" circulating online are usually secondary scams or bundled adware — do not run them against original disks. The correct path is accurate family identification and forensics first, then backup restoration and database structural repair.

Latest activity

  1. In 360's August 2026 report BeijingCrypt no longer charts, while BrzCrypt (.flex), another RDP brute-force hands-on family, rose to second at 11.11%. A new RDP case in China is no longer presumptively BeijingCrypt.

    Sources

  2. 360's June 2026 report still lists baxia 8th among victim search keywords, restating entry via brute-forced RDP and database credentials with hands-on deployment. The family was still producing victims mid-2026.

    Sources

  3. 360's April 2026 report ranks bixi 4th and baxia 5th among victim search keywords and notes both are BeijingCrypt. The family is still active in China under a new .baxia extension, and still has no decryptor.

    Sources

Overview

BeijingCrypt appeared in June 2020 and takes its name from the .beijing extension used by early builds. 360's family analysis notes that it spread in China through weak remote-desktop credentials from the outset, grew month over month from 2021 into the domestic top ten by volume, and has remained a regular presence in Chinese server ransomware cases since.

Rotating extensions are its most distinctive trait: it has used .genesis, .beijing, .520, .file, .360, .fc and .montana, with .halo appearing in early 2023, and 360's October 2025 report recorded .bixi in that period. Frequent changes evade detection and make it hard for victims to find accurate information by searching the extension.

The .360 extension deserves a separate note: the operators deliberately borrowed the name of a well-known Chinese security vendor to confuse victims, and there is no connection to that company. Affected companies consequently end up surrounded by low-quality "decryption service" pages, and some install bundled tools that damage the original data further. Victims are mostly business servers at smaller companies — typically a Windows Server running an ERP system, SQL Server and local backups together, with port 3389 mapped straight to the internet.

How to identify it

Extensions: .beijing, .360, .520, .genesis, .file, .fc, .montana, .halo, .bixi and others. Suffixes rotate frequently, so an unfamiliar extension does not rule this family out.

Ransom notes: typically !RECOVER.txt and !HELP!.txt, dropped into encrypted directories and onto the desktop, giving a primary and backup mailbox and asking for a machine ID.

Intrusion artefacts (the most reliable evidence):

  • Many failed RDP logons (event 4625) followed by a single success (4624, logon type 10).
  • Clusters of authentication failures on database ports 1433 and 3306.
  • Attacker-created administrator accounts, or existing accounts added to the administrators group.
  • Security software uninstalled or terminated, and suspicious new scheduled tasks.
  • Encryption completed in a short window with a manual rhythm: stop services, encrypt, then drop the notes.

Infection vectors

Brute-forced remote desktop followed by hands-on deployment is this family's standard method. 360's analysis states that BeijingCrypt intrudes primarily by brute-forcing port 3389, after which the operator runs the encryptor manually; recent reports also record it obtaining database credentials by brute force and then pushing the ransomware to the device.

The full path is usually: scan for hosts with 3389, 1433 or 3306 open; brute-force administrator, sa and root; disable or uninstall security software, create backdoor accounts and establish persistence; distribute the payload to other internal servers over shares or remote desktop; then terminate database and backup services, delete shadow copies and encrypt. Other vectors include shared folders, vulnerability exploitation and spam.

The structural reason for its prevalence in China: smaller companies expose 3389 directly with simple passwords for remote work; SQL Server runs under the default sa account with an unchanged password; and backups sit on the same machine as production. Stack those three and one successful brute force wipes out the entire dataset.

Encryption behavior

BeijingCrypt uses a hybrid AES-256 plus RSA-2048 scheme: AES-256 for file contents, with the symmetric key protected by an RSA-2048 public key. Key material is per-host, so without the attacker's private key there is no algorithm-level recovery.

Encryption and destructive behaviour: it terminates SQL Server, MySQL, Oracle, mail and backup-agent services before encrypting; encrypts local disks, mapped network drives and reachable shares, which is why NAS devices and file servers are commonly hit; deletes volume shadow copies and restore points; explicitly targets database files (.mdf, .ldf, .bak, .dbf, .ibd), so many victims lose their local backup alongside the database; and writes !RECOVER.txt / !HELP!.txt into encrypted directories and onto the desktop.

On large-file handling: behaviour differs between variants and public sources give no consistent answer, so testing is required — take database files and large archives, analyse the distribution and stride of encrypted blocks and where damaged structures sit, and only then judge whether structure-level repair is viable. Platforms are primarily Windows, with no mature native Linux or ESXi payload observed.

Assess before you act

Recoverability assessment

No public free decryptor exists. There is no official or vendor decryption path for BeijingCrypt, and the "dedicated decryptors" circulating online for .360 or .beijing are mostly secondary scams or bundled adware that damage data when run against original disks.

1. Backups, snapshots and shadow copies The primary path. The operators delete shadow copies and encrypt local backups, but their hands-on style and limited dwell time leave gaps: standalone backup machines with no mapped shares, offline drives and tape, NAS-native snapshots the encrypting process cannot see, cloud object-storage version history, and hypervisor snapshots. Inventory them immediately after isolation so surviving backups are not caught in a second wave.

2. Structure-level repair of database files (verify first) Where large files are only partially encrypted, page-level damage mapping, system-table and allocation repair and table-level extraction become possible, with transaction logs and upstream documents replayed to close the delta. If files are fully encrypted the path is closed, and we say so.

3. Unencrypted copies and hosts never touched Business data usually exists in several places: reports exported from inventory and finance systems, filings to tax authorities and banks, reconciliation statements and copies on staff laptops. Manual deployment has bounded reach, so hosts outside the same credential domain, without mapped shares, or powered off at the time are often intact.

We do not pay ransoms, do not negotiate for clients, and never promise that every file can be decrypted or restored.

Our response plan

Hit by BeijingCrypt ransomware? What to do

  1. Step 1: Containment and evidence preservation

    Immediately remove public port mappings on affected servers (3389, 1433, 3306), block SMB between them and the rest of the internal network, and disable the brute-forced account along with every suspicious newly created administrator account. BeijingCrypt operators commonly leave backdoor accounts behind, and failing to remove them leads to re-encryption during recovery.

    Evidence to preserve: Windows security log 4625/4624 records (establishing the brute-force source IP, success time and account), SQL Server error logs and logon auditing, account and group membership changes, scheduled task and service inventories, records of security software being uninstalled, the original !RECOVER.txt / !HELP!.txt notes, encrypted samples of varying type and size, and matching unencrypted originals wherever they can be found.

    Do not reinstall, do not reformat, and do not run unverified "decryptors" against original disks.

  2. Step 2: Family identification and encryption analysis

    Because BeijingCrypt rotates extensions frequently and is often conflated with Phobos, Makop and Crysis/Dharma in China, accurate identification is a decisive step.

    Evidence used: the ransom-note filename (!RECOVER.txt / !HELP!.txt is characteristic of BeijingCrypt and clearly different from Phobos's info.txt plus info.hta or Makop's readme-warning.txt), the filename rewrite pattern, marker structures in encrypted file headers and footers, payload characteristics, and whether the suffix belongs to the family's known sequence (.beijing, .360, .520, .halo, .bixi and others).

    Encryption analysis follows: sample database files, large archives and ordinary documents to determine whether encryption is partial, the block stride, and where damaged structures sit. This determines whether Step 3 can offer a database repair plan. Residual backdoor accounts and persistence are audited at the same time.

  3. Step 3: Recoverability assessment and recovery planning

    State plainly that no public decryptor exists, then bucket by path:

    • Backup available: verify the recovery point and integrity of standalone backup machines, offline media, NAS snapshots, cloud version history and hypervisor snapshots, confirming they are neither encrypted nor carrying a backdoor.
    • Repair required: sample .mdf/.ldf/.bak/.dbf/.ibd files; where encryption is confirmed partial, give table-level coverage estimates, and where it is full, state honestly that repair is not viable.
    • Side-channel reconstruction: work with operations and finance to inventory report exports, regulatory filings, reconciliation statements and paper vouchers, and assess the reconstructable time range.
    • Unaffected hosts: verify host by host which servers and endpoints can serve as a baseline.
    • Confirmed unrecoverable: listed explicitly.

    Because victims typically have limited IT capacity, the plan should also recommend which systems to restore first to get the business functioning again.

  4. Step 4: Recovery execution

    All work happens on read-only images and copies, leaving original disks untouched, in a clean environment where backdoors have already been removed.

    • Backup restoration: restore core business databases and essential directories first, validating backup integrity and checking for embedded payloads in an isolated environment beforehand.
    • Database repair: where encryption is confirmed partial, map page-level damage in SQL Server, repair system tables and allocation structures and extract table by table; for Oracle, combine datafile header repair with archive-log application; for MySQL, process .ibd tablespaces individually and rebuild the dictionary.
    • Delta reconstruction: replay unaffected transaction logs, archive logs and upstream transaction feeds.
    • Files and NAS: restore in batches by department priority.
    • Side-channel reload: import reconstructed reports and documents back into the system by business period.

    Every batch ships with verification records: record-count reconciliation, sampled key document checks and application functionality tests. The recovery environment joins the production network only once it is confirmed clean.

  5. Step 5: Attribution, hardening and sign-off

    The investigation report must state: brute-force source IPs and timeline, which account and which port succeeded (RDP or database), attacker-created accounts and persistence, which hosts the manual deployment reached, and why the backups were encrypted too.

    Verifiable hardening checklist:

    • Remove all public mappings of 3389, 1433 and 3306, routing remote access through VPN or a zero-trust gateway with enforced multi-factor authentication.
    • Delete backdoor accounts, set strong passwords on administrator/sa/root with source-IP restrictions, and enable lockout policies.
    • Segment servers to limit internal RDP and SMB reachability.
    • Move backups to offline/off-site plus immutable storage, physically separate backup media from production servers, and run regular real restore drills.
    • Stop hosting databases on the same machine as the application, and disable dangerous extensions such as xp_cmdshell.
    • Deploy EDR with a closed alert loop for failed logons, account creation and security-software removal.

    The engagement closes with an incident report and a hardening sign-off checklist.

Risk warning

What not to do

  • Do not download or run programs advertised as a "dedicated .360 decryptor" or ".beijing decryption tool". This family has no public decryptor; such programs are usually secondary scams or bundled adware and damage data further when run on original disks.
  • Do not read the .360 extension as any connection to the Chinese security vendor of that name. It is deliberate brand borrowing to confuse victims and nothing more.
  • Do not reinstall the OS or reformat affected volumes, and do not rebuild partitions to "clean the virus" — that destroys the fragment-recovery option as well.
  • Do not restore network connectivity before backdoor accounts are removed. Operators routinely leave self-created administrator accounts, and re-encryption during recovery is common.
  • Do not delete ransom notes, encrypted samples or the Windows security log — 4625/4624 records are the core evidence for the brute-force entry point and timeline.
  • Do not email the addresses in the note to pay on your own. Payment guarantees no working decryptor and marks the company as willing to pay.

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.

+86 15639272850See contact details

Related scenarios

Related industries

Similar families

Related questions

FAQ

BeijingCrypt Frequently asked questions

  • What is the .360 extension ransomware? Is it related to the 360 company?

    There is no connection. .360 is one of the extensions used by the BeijingCrypt family; the operators deliberately borrow the name of a well-known Chinese security vendor to mislead victims into thinking it relates to security software, sending them down the wrong path when searching for help.

    BeijingCrypt is named for the .beijing extension used by early builds and has since used .genesis, .520, .file, .fc, .montana, .halo and .bixi among others. The ransom-note filename is the more reliable indicator: !RECOVER.txt and !HELP!.txt are characteristic of this family.

    Be aware that searching for ".360 ransomware decryption" surfaces many low-quality pages and supposed dedicated tools. The family has no public free decryptor, and such programs should never be run against original disks.

  • Can files encrypted by BeijingCrypt be decrypted?

    No free public decryptor exists. The family encrypts file contents with AES-256 and protects the symmetric key with RSA-2048; key material is per-host, so without the attacker's private key there is no algorithm-level recovery, and neither No More Ransom nor vendor libraries list a tool.

    Recovery effort should therefore go to the realistic paths: inventorying backups and snapshots (standalone backup machines, offline media, NAS snapshots, cloud version history, hypervisor snapshots), empirically testing structure-level repair on database files, sweeping for unencrypted side-channel copies, and identifying hosts the operator never touched. Accurate family identification and forensics followed by a plan with coverage estimates is more valuable than continuing to hunt for a decryptor.

  • Our SQL Server database was encrypted — is the .mdf file salvageable?

    That requires encryption analysis before it can be answered. BeijingCrypt explicitly targets .mdf, .ldf and .bak files, but variants differ in how they handle large files and public sources give no consistent answer.

    The correct approach: image the volume holding the database files read-only, then analyse the distribution and stride of encrypted blocks in the .mdf and .ldf. Depending on how encryption was applied — if it is partial, many intact data pages remain, allowing page-level damage mapping, system-table and allocation repair and table-level extraction, with an undamaged transaction log and upstream transaction feeds closing the delta; if it is full, the repair path does not exist and we say so, redirecting effort to backups, side-channel copies and business-side reconstruction.

    In either case, do not run DBCC repair or force-attach against original disks — those writes destroy the structures repair depends on.

  • Why were our backups encrypted as well?

    Because the backups sat inside the same reachable scope as production data. BeijingCrypt is deployed by hand after a brute-force logon, and it encrypts local disks, mapped network drives and reachable shares while deleting shadow copies and stopping backup-agent services. Any backup on another partition of the same machine, on a mapped drive, or on a NAS share reachable with the same credentials is therefore encrypted too.

    This is the single most valuable thing to change: backups need at least one offline or immutable copy — offline removable media, write-protected object storage with object lock, or a backup server that requires separate credentials and maps no shares. Run regular real restore drills so you know the backup works rather than merely that the job "reported success". During recovery, do not reconnect to the network before backdoor accounts are removed and port mappings withdrawn, or freshly restored data may be encrypted again.

  • How do I tell BeijingCrypt apart from Phobos and Makop?

    All three use brute-forced RDP and hands-on deployment in China, which makes them easy to confuse, but the distinguishing evidence is clear — look at the ransom-note filename:

    • BeijingCrypt: !RECOVER.txt, !HELP!.txt
    • Phobos lineage (including .faust, .elbie, .eking): info.txt plus info.hta, with filenames like .id[8 chars-4 digits].[email].suffix
    • Makop lineage (including .mkp, .baseus): readme-warning.txt, with filenames like .[8-char ID].[email].suffix

    This is not an academic distinction: it changes the response. Phobos has an official free decryptor released by Japan's National Police Agency in July 2025, while BeijingCrypt and Makop currently have no public decryption path. Misidentifying the family wastes time on useless tools and risks damaging operations on original disks. Hand the notes and a few encrypted samples to a response team and identification usually takes hours.

Sources

External links are provided for reference only. The content is published by third parties and does not represent our position.

Updated