Ransomware is the worst kind of disaster because the latest clean restore point is unknown. As complex as disaster recovery (DR) is, at the end of the day simply point to the latest restore point and recover as fast as physics will allow. Cyber recovery (CR) on the other hand is far more difficult for several reasons listed in the table below. The main reason being that the latest clean backup is unknown. Often times the critical path to a successful cyber recovery is finding a clean restore point.
Unlike DR restore points cannot just be restored directly back into production. CR requires workloads to be scanned by the latest AV signatures to ensure malware isn't being injected back into the environment. Without a proper incident response plan, data protection teams will spend days if not weeks restoring workloads for forensics/secops teams to scan only to find the restore points still infected.
With Veeam v12.1 YARA (Yet Another Recursive Acronym) rules combined with multiple inline detection capabilities organizations can proactively find the latest clean backup without doing a full restore. Whether it is Veeam inline scanning or XDR tools detecting indicators of compromise (IOCs) YARA rules are a quick way to confirm the latest clean restore point. For example, below illustrates Veeam finding IOCs in the last two restore points.
Once security has determined an attack is taking place and activated the incident response plan, YARA is a quick way to find the most recent clean backup. In this scenario, secops knows what malicious attack took place. Whether it's an encryption pattern, shellcode that exploited a vulnerability, specific text file, etc a YARA rule can quickly scan restore points until it finds a clean backup free of any IOCs.
rule File_Encryption_Ransomware {
meta:
description = "Searches for indicators of file encryption ransomware"
author = "Brad Linch"
strings:
$ransom_note_extension = ".txt"
$encryption_pattern = "BMhmeWMfXgoRKUd7"
$shellcode = { 31 C0 31 DB B0 05 CD 80 31 C0 31 DB B0 27 CD 80 }
condition:
any of them
}The reason this is so much more powerful than mounting a backup and running AV scans is because a properly created YARA rule takes minutes to scan compared to hours for an AV scan. Below each restore point scan took a little over one minute on a 270 GB VM. Powerful stuff!
As mentioned earlier though, no incident response team is going to simply scan a backup with a YARA rule and restore back into production. They are still going to scan with the latest AV signatures to ensure malware isn't reinfecting the environment. This is why Veeam still offers the ability to automatically scan backups with AV before restoring to prod. The combination of the two allows organizations to orchestrate the cyber recovery process. Use YARA and Veeam inline scanning to find what looks to be the latest clean backup quickly, and then use AV to do a final scan before restoring backing to production.
YARA rules are powerful because there are endless possibilities in what they can scan for, but they are also daunting for that same reason. Below are a few YARA examples for different scenarios to help get started. Feel free to skim past if you don't care. :)
Search for Hash Value Patterns:
This YARA rule will look for md5, sha1 and sha256 hash files on workloads as this can be a sign of malicious behavior. Taking any hash files found and searching in tools like Virus Total can inform you if the file is known to be malicious.
rule HashSearch {
meta:
description = "Searches for specific hash values in files"
author = "Brad Linch"
strings:
$md5_hash = { [0-9A-F]{32} }
$sha1_hash = { [0-9A-F]{40} }
$sha256_hash = { [0-9A-F]{64} }
condition:
any of them
}
Search for Zero Day Exploits:
XDR tools and signature based scanning tools don't know what they don't know. Below is an example of a YARA rule to scan for zero day attacks by looking for shellcode deployed, executed bash scripts and specific key words that might be signs of an attack.
rule ZeroDayDetection {
meta:
description = "Searches for indications of potential zero-day attacks"
author = "Brad Linch"
strings:
$shellcode = { 31 C0 31 DB B0 05 CD 80 31 C0 31 DB B0 27 CD 80 }
$cmdline_pattern = /(powershell|cmd|bash) ([A-Za-z0-9]+[-_\w]\b ?)
$exploit_pattern = "exploit"
$evasive_behavior = "sleep"
condition:
any of them
}Search for Malicious Files:
Below is an example of searching for specific malicious file.
rule Detect_Malicious_Files {
meta:
description = "Searches for indicators of malicious files"
author = "Brad Linch"
strings:
$rar_exe = "Rar!\x1a\x07\x00"
$pe_executable = "MZ"
$pe_exports = "USER32.dll"
condition:
any of them
}Suspicious Network Connections:
Lastly, is a YARA rule example searching for IPs in log files as potential suspicious network connections.
rule Suspicious_Network_Connections {
meta:
description = "Searches for suspicious network connections in logs"
author = "Brad Linch"
strings:
$ip_pattern = /[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]+/
$domain_pattern = /(\w+\.){2,}\w+/
condition:
$ip_pattern or $domain_pattern
}Conclusion:
The elephant in the room in a lot of these discussions I have with organizations is do you really have a cyber recovery plan or do you have a disaster recovery plan. They are two completely different events to plan for. Cyber Recovery requires planning on how to find the latest clean backup as quickly as possible, how to restore to an alternate location if the primary DC is completely off limits, and identifying mission critical workloads you need to restore first as fast as possible.
Comments