In July 2026, On-Site Technology responded to a ransomware attack on a manufacturing business with roughly 30 users. The group behind it, which calls itself The Gentlemen, encrypted the production server and business data. Before that, it went after the backups, including two offsite copies held with two separate cloud services, and deleted them. Here is how the attack worked, how to spot it, and the settings that block it.

What happened, step by step

The attack followed a familiar pattern: get in, collect credentials, destroy recovery options, then encrypt.

1. Credentials stored in plain text

Plain-text credentials stored on the network are believed to have helped the attackers move deeper once they had a foothold.

2. A script run from a service account’s Downloads folder

Logs show a PowerShell script executed from the Downloads folder of a service account. The script was built to decrypt passwords saved by the backup software, and it had been deleted by the time we responded.

3. Cloud storage keys pulled from the backup server

The environment used a leading enterprise backup platform that replicated backups to S3-compatible cloud storage. The script appears to have decrypted the cloud storage access keys saved in the backup software’s configuration.

4. The primary offsite copy deleted

With those keys, the attackers connected to the storage provider using rclone, a common open-source file-sync tool, and deleted the backup bucket. Once deleted, the data could not be recovered.

5. The secondary offsite copy deleted

A NAS device held a second backup copy and synced it to the NAS manufacturer’s own cloud backup service. The attackers issued a remote delete command against that cloud container as well.

6. Local backups and servers encrypted

The attackers then encrypted the local backups, the production server, and business data.

Why this technique works

Many backup deployments share the same weakness. The credentials needed to reach every copy, including the offsite ones, live on the network the attacker is already inside.

Backup software has to keep cloud storage keys where it can use them, so an attacker who controls the backup server can often recover them. Unless the bucket enforces Object Lock in compliance mode, anyone holding keys with delete rights can remove the data. With compliance-mode locking, the delete request is refused even when the keys are valid.

The encryption offers no shortcut either. This ransomware family encrypts each file with its own key using XChaCha20 with X25519 key exchange, so brute force is not an option. One detail is useful for responders: it encrypts only portions of large files to work faster, so large files such as database backups may be partially recoverable by a specialized data-recovery firm.

Mapped to MITRE ATT&CK

What we recommend

If you back up to cloud storage, review your setup against these steps.

1. Turn on Object Lock in compliance mode for every backup bucket, and immutable snapshots for NAS devices and their cloud backup targets. Nobody, including you, can delete locked data before its retention date. That is the point.
2. Give the backup server storage keys that can write and read, but not delete. Keep the storage account’s admin credentials off the network entirely.
3. On backup servers, use AppLocker or WDAC to stop PowerShell from running out of user Downloads folders, and run service accounts in Constrained Language Mode.
4. Move every shared credential into a password manager with MFA. Then search your workstations for files named like “passwords” or “logins”. You will probably find one.
5. Treat the backup server like a domain controller. It holds the keys to your last line of defense, so its logs belong in front of a managed detection and response team watching for the behaviors above.

If you are hit, preserve memory before rebooting anything. RAM, hiberfil.sys and the pagefile can hold key material a forensics firm may be able to use. Report the attack to the FBI through IC3 and to CISA, and check No More Ransom for a decryptor.

References

Technique IDs from the MITRE ATT&CK Enterprise matrix. Details of this incident come from On-Site Technology’s own response work; the client is not identified.