What is median dwell time? "The global median dwell time is the number of days that an attacker is in a computing environment before detection. Over the past decade, there has been a marked reduction in median dwell time, from just over one year (416 days) in 2011 to just under one month (24 days) in 2020."
Some of the following symptoms can point to an active ransomware infection in progress...
Steady (non-bursts) increase in workload for a volume: Ransomware will likely steadily encrypt volume data. As a consequence, it will generate an increase in storage utilization.
The added workload is approximately 50% read, and 50% write: The additional IO is likely to be well balanced between reads and writes as it reads and overwrites with encrypted data.
The added workload has 0% compression and 0% deduplication: Encrypted data does not deduplicate or compress. A drastic reduction in DeCo efficiency or a significant increase in incremental backups size is an early warning.
NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, and Recover. With this in mind and per "NIST SP 800-61 Detection and Analysis - Section 3.2", Veeam One offers...
CPU Usage (Warning at 70% - Error at 80%) -AND-
Datastore Write Rate -OR- Network Transmit Rate (Warning at 40Mb/s - Error at 60Mb/s)
Note: Identifying potential ransomware activity with Veeam ONE - 6 min read
Note: “Possible Ransomware Activity” alarm (CPU and Disk Writes) - 6 min read
Incremental Backup Sizes (Error at 200%)
Note: "Suspicious incremental backup size" alarm - 6 min read
What are "Ransomware Canaries"?
"Create an office document with a name that makes it obvious to your users that they shouldn't touch it and that will appear at the top or early in the file listing (keep in mind that ransomware usually traverses directories depth-first). Enable object auditing on the server for success events. Give the canary an SACL to monitor for success events on create/modification/delete/takeownership/changepermissions. Create a scheduled task triggered by "Security" log event ID 4663 with "Microsoft-Windows-Security-Auditing" source, and an action that launches a powershell script with the arguments "$(SubjectDomainName)\$(SubjectUserName)" and "$(FileName)". The powershell script should check that the user is not a computer object (account name ends in "$") because the server will log itself as modifying the file before the user account does, and you may also wish to have it check the filename if you have other SACLs set up for other purposes. Have that script run the share blocking script above with a valid user, and it would also be a good idea to have it send an alert email using "Send-MailMessage"."
Anti-Ransomware File System Resource Manager (FSRM) Lists
Note 1: “You may use the 'VM Change Rate History' and 'Job History' reports to get more information about the VM size changes and act from there. You may also want to involve the owner of the applications running on this VM to get more understanding of the situation once it's understood when exactly changes that caused the alarm to trigger happened."
Note 2: "It may be natural for a VM to have a high change rate, depending on what kind of applications are running there. In this case, you may adjust alarm thresholds accordingly or exclude that VM from the original alarm and create a separate individual alarm for it with specific thresholds."
