Ransomware Detection During a NAS Backup Job

Treat the alert as a live incident until proven otherwise. The order should protect evidence and recovery points before restoring service.

1. Contain the source: isolate the affected file servers from the network using the incident response process, not by deleting data. Identify which accounts and hosts wrote the .locked files.
2. Protect the backup control plane: disable or rotate the domain-administrator service account used for backups, enforce MFA for Cohesity administrators, and review active sessions. The backup account may be compromised; do not let it delete snapshots.
3. Do not stop or delete blindly: the running backup job may be capturing the encrypted state, which is useful evidence, but it may also overwrite nothing because Cohesity snapshots are immutable point-in-time copies. Let the job finish only if it does not consume critical capacity; otherwise pause it and record why.
4. Identify clean recovery points: use DataHawk details and file-level inspection to find the last snapshot before the first .locked file appeared. Restore a sample to an isolated location, verify file integrity, and scan before production restore.
5. Preserve snapshots: place a legal hold or extend retention on the relevant snapshots, and restrict deletion rights. Notify the incident response and legal teams.

Recovery should start from the newest verified-clean snapshot, not from the newest snapshot. A fast restore of encrypted data is not recovery.

Deleting the last 24 hours of snapshots destroys the most likely clean recovery points and removes evidence of when the encryption began. The newest snapshots may include the pre-encryption state; the fact that a later snapshot is bad does not make the earlier ones disposable. Deleting them also plays into the attacker's goal: ransomware operators often target backups first so that recovery requires paying.

A new full backup is also based on a false assumption. If the source is still infected, the new full captures encrypted or malicious data and may overwrite retention if the policy is not immutable. Cohesity's incremental-forever design means a new full is not needed to establish a clean chain; the correct action is to select a known-good snapshot and restore from it.

Instead:

• Preserve all snapshots around the incident window and restrict deletion to a break-glass account.
• Verify the last clean snapshot with file listings, checksums, and malware scanning on an isolated restore.
• Restore to a new share or alternate host first, not over the production share.
• After containment, take a new backup only from a verified-clean source and label it as a post-incident baseline.
• Enable DataLock or equivalent immutability on the archive and on critical local snapshots so that a compromised administrator cannot delete recovery points.

The incident exposed three separate weaknesses: excessive identity privilege, missing immutability, and a backup design that is too dependent on one control plane.

Identity: replace the domain-administrator backup account with a least-privilege service account scoped to the required shares and backup operations. Enforce MFA for all Cohesity administrators, integrate SSO where possible, and separate the backup operator role from the role that can delete snapshots or change retention. Use break-glass accounts only with logging and approval.

Policy: create a NAS protection policy with a realistic schedule and retention. The 9-hour run indicates that the 6-hour window is not achievable with full metadata scans; use change-based scanning where supported, split the three file servers into separate protection groups, and monitor scan duration. Do not let a single job failure hide the entire NAS estate.

Immutability: enable DataLock on the archive repository and on critical backup snapshots with a retention period that exceeds the expected detection time. Immutability must cover the ability to delete, not just the ability to write. Test that an administrator cannot shorten retention.

Detection and isolation: keep DataHawk anomaly detection enabled and route alerts to the SOC. Maintain an isolated or air-gapped copy for the most critical finance data. Test a file-level restore quarterly and record the time to recover, because a clean snapshot that cannot be restored within the business window is only partial protection.