Veeam v13: Malware Detection, YARA Rules, and the Verified Recovery Loop

Veeam v13 Series | Component: VBR v13 | Audience: Enterprise Architects, Security and Compliance Teams, Hands-on Sysadmins

Veeam's malware detection stack has grown into something genuinely useful, and most environments still have it mostly off or configured with default settings that catch a fraction of what it's capable of catching. The three detection methods work differently and catch different things. YARA rules add a threat intelligence layer that most shops skip because the documentation on how to actually write and use them is scattered. And what happens after a detection fires is where most teams lose the thread entirely.

This article covers all of it. How each detection method works, what it's actually looking for, and when to use which one. YARA rules in depth. What to do the moment something is flagged, and exactly what happens to your restore points when you mark something clean. The VM isolation option and when it makes sense. And then a set of PowerShell scripts to automate the response workflow and wire SureBackup into the loop so you're not doing this all manually.

1. The Three Detection Methods and What They Actually Do

The three methods are Guest Indexing Data Scan, Inline Scan, and Scan Backup. They run at different points in the backup lifecycle, look for different things, and have different performance impacts. You want all three running eventually, but you don't turn them all on at once.

Guest Indexing Data Scan

This is the most efficient detection method because it's piggybacking on work the backup job is already doing. When guest file system indexing is enabled on a job, Veeam builds an index of every file inside the VM. The Guest Indexing Data Scan analyzes that index for signs of trouble.

It's looking for four specific things. Known suspicious files and extensions (a maintained list of file types associated with ransomware activity). Indicators of compromise, which includes files dropped by known attack tools like Mimikatz, Cobalt Strike artifacts, and similar. Mass file deletions, where a large number of files disappeared between backup runs. And mass extension changes, where a large proportion of files had their extensions changed, which is the signature pattern of encryption in progress.

The comparison happens against the nearest restore point created within the last 25 hours, or the nearest restore point within the past 30 days if nothing exists within 25 hours. If an anomaly is detected, a malware detection event is created and the restore point is marked Suspicious.

To enable it: on the backup job, go to the Guest Processing tab, enable Guest OS file system indexing, and set it to Index everything. Without indexing there's no index to scan. The scan itself is controlled in the main menu under Malware Detection, File Detection.

Inline Scan (Entropy Detection)

Inline Scan runs during the backup process itself, analyzing data blocks as they move through the proxy. It's looking for two things: high entropy data blocks that suggest file encryption is active in the VM right now, and text artifacts embedded in data blocks like Tor onion addresses (56 character strings in [a-z2-7]{56}.onion format) and ransomware notes with known content patterns from families like Clop and Medusa.

The entropy detection is genuinely powerful because it catches active encryption that hasn't finished yet. If ransomware is mid process when your backup runs, the inline scan can flag it before the backup job even completes. That's earlier detection than any file based method can offer.

The cost is real though. Community testing from Veeam's engineering summits has reported roughly 25 to 30% additional CPU load per proxy when this is enabled. The official docs don't publish a specific figure, so monitor your actual proxy utilization after enabling it. It only works on NTFS, ext4, ext3, and ext2 file systems. Enable it on proxies that have CPU headroom. Don't enable it globally if you're already running your proxies near capacity during backup windows.

Enable inline scan in the main menu, Malware Detection, Encryption Detection. You'll see options for entropy analysis and text artifact detection separately. Enable both unless you have a specific reason not to.

Scan Backup

Scan Backup is the heaviest method and the most thorough. It mounts existing restore points and scans the actual files inside them using Veeam Threat Hunter (Veeam's built in signature engine), your own antivirus tool via an XML configuration file, or YARA rules. This is how you scan historical restore points for threats that weren't known when the backup was taken, or how you validate that a restore point is genuinely clean before you restore from it.

Run it from the Home view: right click a backup job, select Scan Backup. You'll configure the date range to scan, the scan engines to use, and what to do when something is found. It runs outside the backup window and doesn't impact active jobs.

2. YARA Rules: Deep Coverage

YARA is a pattern matching tool that lets you describe what malware looks like in terms of strings, byte sequences, and conditions, then run that description against files to find matches. The name stands for Yet Another Recursive Acronym, which tells you something about the community that built it.

In the context of Veeam, YARA rules run during Scan Backup and Secure Restore sessions. They scan the files inside mounted restore points looking for the patterns you've defined. If you write a rule that matches the byte signature of a specific ransomware family, Veeam will find that signature in any restore point where it's present, including restore points taken before the ransomware fully executed and before your endpoint detection had any idea it was there.

How a YARA Rule Is Structured

Every YARA rule has three sections: meta (optional documentation), strings (the patterns to look for), and condition (the logic that determines a match). Here's a rule that detects a common ransomware note pattern:

rule Ransomware_Note_Generic
{
    meta:
        description = "Detects common ransomware note file names and content"
        author      = "Your Name"
        date        = "2026-03-01"
        severity    = "high"

    strings:
        // File name patterns (case insensitive)
        $note1 = "RECOVER-FILES.txt" nocase
        $note2 = "HOW_TO_DECRYPT.txt" nocase
        $note3 = "README_FOR_DECRYPT.txt" nocase
        $note4 = "YOUR_FILES_ARE_ENCRYPTED" nocase

        // Onion address pattern
        $onion = /[a-z2-7]{56}\.onion/ nocase

        // Common ransom demand language
        $demand1 = "your files have been encrypted" nocase
        $demand2 = "send bitcoin to" nocase
        $demand3 = "unique ID" nocase wide

    condition:
        any of ($note*) or $onion or
        (2 of ($demand*))
}

The strings section defines your patterns. Text strings accept modifiers: nocase makes matching case insensitive. wide handles UTF-16 encoded strings (common in Windows executables). fullword requires the string to be delimited by non-alphanumeric characters. Hex patterns use curly braces and allow wildcards with question marks for unknown bytes.

The condition section is where you write the detection logic. any of ($note*) matches if any string starting with "note" is found. 2 of ($demand*) requires at least two demand strings to be present, which reduces false positives compared to a single string match. You can combine conditions with and, or, and not.

A More Targeted Rule: LockBit Indicators

rule LockBit3_Indicators
{
    meta:
        description = "Detects LockBit 3.0 ransomware artifacts"
        author      = "Your Name"
        date        = "2026-03-01"
        reference   = "https://www.cisa.gov/lockbit"

    strings:
        // LockBit 3.0 ransom note filename pattern
        $note = /[A-Z0-9]{8,16}\.README\.txt/ nocase

        // Characteristic mutex string pattern
        $mutex = { 47 6C 6F 62 61 6C 5C 4C 6F 63 6B 42 69 74 }

        // Extension pattern LockBit uses post-encryption
        $ext = /\.[a-z0-9]{9}$/ nocase

        // Registry key often dropped
        $reg = "HKEY_CURRENT_USER\\Software\\LockBit" nocase

        // Process kill list entries
        $proc1 = "vssadmin delete shadows" nocase
        $proc2 = "bcdedit /set" nocase
        $proc3 = "wbadmin delete catalog" nocase

    condition:
        $note or $mutex or $reg or
        2 of ($proc*)
}

Suppressing Events Without Suppressing Detection

Sometimes you want a YARA scan to look for something without creating a malware detection event. Maybe you're hunting for sensitive data patterns (PII, credentials) rather than malware, and you want warning output without triggering incident response workflows. Add the SuppressMalwareDetectionNotification tag to the rule name:

rule SensitiveData_SSN_Pattern : SuppressMalwareDetectionNotification
{
    meta:
        description = "Detect SSN patterns in backup data - audit use only"

    strings:
        $ssn = /\b[0-9]{3}-[0-9]{2}-[0-9]{4}\b/

    condition:
        $ssn
}

With this tag, the Scan Backup session completes with Warning status instead of Failed, and no malware detection event is created. The scan results still show what was found.

Where to Put Your Rules and How Veeam Finds Them

On Windows: C:\Program Files\Veeam\Backup and Replication\Backup\YaraRules\

On Linux (VSA): /var/lib/veeam/yara_rules/

Files must have a .yara or .yar extension. Veeam doesn't watch the directory for changes. When you run a Scan Backup or Secure Restore and select a YARA rule, you're pointing to a specific file in that directory. Veeam reads it at scan time.

Where to Get Rules You Didn't Write Yourself

Ransomware.live maintains free YARA rules for over 60 ransomware families, updated as new variants emerge. The community rules in Florian Roth's signature base repository on GitHub cover a much broader threat landscape. The CISA and MITRE ATT&CK repositories publish IoC based rules for known attack campaigns. Any of these can be dropped into the Veeam YaraRules directory and selected during a scan.

Keeping Rules Current with PowerShell

Stale YARA rules are barely better than no rules. Ransomware families evolve. If your rules were written six months ago and haven't been updated, you're only catching the old variants. Automate rule updates with a scheduled task:

# Run as a scheduled task weekly on the VBR server
# Adjust $RulesSource to your trusted rule repository

$YaraDir    = "C:\Program Files\Veeam\Backup and Replication\Backup\YaraRules"
$RulesSource = "https://raw.githubusercontent.com/Neo23x0/signature-base/master/yara"
$LogFile    = "C:\ProgramData\Veeam\Backup\yara_update.log"

function Write-Log {
    param([string]$Message)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$timestamp  $Message" | Out-File -FilePath $LogFile -Append
}

Write-Log "Starting YARA rule update"

# Ensure rules directory exists
if (-not (Test-Path $YaraDir)) {
    New-Item -ItemType Directory -Path $YaraDir | Out-Null
    Write-Log "Created YaraRules directory"
}

# Download specific rule files - enumerate the ones you want to maintain
$RuleFiles = @(
    "ransomware_generic.yar",
    "crime_lockbit.yar",
    "crime_ryuk.yar",
    "crime_blackcat.yar"
)

$updated = 0
$failed  = 0

foreach ($file in $RuleFiles) {
    $url  = "$RulesSource/$file"
    $dest = Join-Path $YaraDir $file

    try {
        $response = Invoke-WebRequest -Uri $url -UseBasicParsing -TimeoutSec 30
        $response.Content | Out-File -FilePath $dest -Encoding UTF8 -Force
        Write-Log "Updated: $file"
        $updated++
    } catch {
        Write-Log "FAILED: $file - $($_.Exception.Message)"
        $failed++
    }
}

Write-Log "Update complete. Updated: $updated, Failed: $failed"
Write-Log "---"

3. When Something Gets Flagged: What Actually Happens

A detection event fires. Here's what Veeam has done and what you're looking at.

The restore point that triggered the detection is now marked either Suspicious or Infected. Suspicious means the detection method found anomalous behavior that could indicate malware. Infected means the scan found a specific signature match (AV or YARA) that confirmed presence of known malware. These aren't interchangeable. Suspicious is "something looks wrong." Infected is "we found it."

The affected machine appears in the Inventory view under the Malware Detection node. Every restore point from the detection event forward is marked. Restore points before the detection event are left with their previous status, which matters a lot when you're trying to find a clean restore point to recover from.

Your First Move: Read the Logs

Before you do anything else, read the detection log. It tells you what was found, where, and when. That information determines every decision that follows.

• Windows log location: C:\ProgramData\Veeam\Backup\Malware_Detection_Logs\
• Linux (VSA) log location: /var/log/VeeamBackup/Malware_Detection_Logs/

For Guest Indexing and Inline detections, the log tells you exactly which file names, extensions, or entropy patterns triggered the event. For YARA detections, it tells you which rule matched and which file it matched in. For AV detections, it tells you the threat name and the infected file path.

Second Move: Run Scan Backup Against the Flagged Points

Guest Indexing and Inline detections tell you something looks wrong. They don't tell you definitively what's there. Before you make any decisions about marking clean or proceeding with response, run a Scan Backup session against the flagged restore points with Veeam Threat Hunter and your best YARA rules. That gives you a more definitive answer.

1. Home view, right click the backup job with the flagged machine, select Scan Backup.
2. Set the date range to cover from just before the first detection event through the most recent restore point. You want to scan the entire window of potentially affected points.
3. Enable Veeam Threat Hunter. Enable YARA scan with your most relevant rules. Enable AV scan if you have an AV tool configured in the antivirus XML.
4. Under "if malware is found," set the behavior to mark the restore point as infected. Don't set it to delete or quarantine on first run. You want to assess before you act.
5. Let the scan complete. Read the results before touching the malware status of anything.

Isolating the VM: When and How

If your Scan Backup comes back with confirmed infection rather than a suspicious signal, the next question is what to do with the live VM. Veeam's isolation option in the context of malware response is Instant Recovery into an isolated network. You're not freezing or quarantining the production VM through Veeam directly -- that's your hypervisor's job. But Veeam lets you boot the restore point into an isolated lab environment for forensic investigation without touching production.

To do this: right click the restore point, select Instant Recovery, and on the network settings step, set the VM to connect to an isolated portgroup with no production network access. This is the same isolated lab that SureBackup uses. You can inspect the VM, run additional forensic tools against it, and determine the blast radius without the risk of the infected workload communicating with anything on the production network.

If you want to actually quarantine the production VM, do that at the hypervisor level. In vSphere, change the VM's network adapter to an isolated portgroup in the vSphere client. That's not a Veeam action, but it's the right one to take in parallel.

4. Marking Clean: What It Does and What It Doesn't Do

This is where most teams make mistakes because the behavior differs based on which option you choose, and the difference matters a lot.

The Two Paths to Marking Clean

When you right click a machine in the Malware Detection node and select Mark as clean, you get a dialog with two different scenarios and different checkbox options depending on which applies.

Scenario 1: You actually cleaned the machine of malware. The malware was real. You remediated it. In this case, leave the "Mark restore points affected by corresponding detection events as clean" box unchecked. Previous restore points keep their Suspicious or Infected status because they genuinely were. All future restore points will be marked clean unless a new detection event fires.

Scenario 2: The detection was a false positive. The detection fired but after investigation there was no actual malware. Check the "Mark restore points affected by corresponding detection events as clean" box. This retroactively marks the affected restore points as clean. Future restore points will not be flagged unless a new event fires.

Marking Individual Restore Points

You can also change the status of specific restore points without touching the the machine status. In the Home view, open the job properties, navigate to the specific machine, right click a restore point, and select Malware, Mark as clean or Mark as infected. This is how you manually mark a specific point as your known clean recovery target even if the surrounding points are still flagged.

5. Wiring SureBackup Into the Response Workflow

After a malware event and after you've investigated, the last thing you want to do is restore from a point you've marked clean and discover it doesn't actually boot or the application doesn't start. SureBackup belongs in the response workflow, not just in the scheduled verification cycle.

The flow looks like this: detection fires, Scan Backup runs with full YARA and AV coverage, you find the last clean restore point, you mark it, and then you run SureBackup against that specific point before any restore happens. If SureBackup passes, you have a verified clean restore point. If it fails, you go back one more point and repeat.

To run SureBackup against a specific restore point rather than the latest: in the SureBackup job configuration, select the specific restore point date rather than the default "latest." This is exactly the use case SureBackup was built for, and most environments only discover this capability after they need it.

6. Automating the Response Workflow with PowerShell

When a malware detection event fires at 3am, you want a script doing the initial triage work, not a phone call to whoever is on call. These scripts handle the detection to investigation to SureBackup loop.

Query All Current Malware Detection Events

Connect-VBRServer -Server "vbr-server.domain.local"

$detectedObjects = Get-VBRMalwareDetectionObject

foreach ($obj in $detectedObjects) {
    [PSCustomObject]@{
        MachineName  = $obj.Name
        Status       = $obj.MalwareStatus
        DetectedAt   = $obj.DetectionTime
        JobName      = $obj.JobName
        Details      = $obj.Details
    }
} | Format-Table -AutoSize

Disconnect-VBRServer

Trigger Scan Backup on All Flagged Machines

Connect-VBRServer -Server "vbr-server.domain.local"

# Get all machines currently in Suspicious or Infected state
$suspectMachines = Get-VBRMalwareDetectionObject |
    Where-Object { $_.MalwareStatus -in @("Suspicious","Infected") }

if ($suspectMachines.Count -eq 0) {
    Write-Host "No suspicious machines found."
    Disconnect-VBRServer
    exit 0
}

Write-Host "Found $($suspectMachines.Count) machines to investigate"

foreach ($machine in $suspectMachines) {
    Write-Host "Initiating Scan Backup for: $($machine.Name)"

    # Get the backup object for this machine
    $backup = Get-VBRBackup | Where-Object {
        $_.GetObjectRestorePoints() |
        Where-Object { $_.Name -eq $machine.Name }
    } | Select-Object -First 1

    if ($null -eq $backup) {
        Write-Host "  WARNING: Could not find backup for $($machine.Name). Skipping."
        continue
    }

    # Start Scan Backup session
    # The scan covers the last 7 days by default; adjust StartTime as needed
    # Get backup objects for this machine from the backup
    $backupObjects = Get-VBRBackupObject -Backup $backup |
        Where-Object { $_.Name -eq $machine.Name }

    if ($null -eq $backupObjects -or $backupObjects.Count -eq 0) {
        Write-Host "  WARNING: No backup objects found for $($machine.Name). Skipping."
        continue
    }

    # Start Scan Backup session using Start-VBRScanBackup
    $scanResult = Start-VBRScanBackup `
        -BackupObject $backupObjects `
        -EnableThreatHunter $true

    Write-Host "  Scan started for $($machine.Name). Session ID: $($scanResult.Id)"
}

Disconnect-VBRServer

Find the Last Clean Restore Point for a Machine

param(
    [Parameter(Mandatory)][string]$MachineName,
    [string]$VBRServer = "vbr-server.domain.local"
)

Connect-VBRServer -Server $VBRServer

# Get all restore points for this machine, newest first
# Find the backup that contains this machine
$machineBackup = Get-VBRBackup | Where-Object {
    (Get-VBRBackupObject -Backup $_).Name -contains $MachineName
} | Select-Object -First 1

if ($null -eq $machineBackup) {
    Write-Error "No backup found containing machine '$MachineName'"
    Disconnect-VBRServer
    exit 1
}

# Get restore points for this machine using Get-VBRObjectRestorePoint
$allPoints = Get-VBRObjectRestorePoint -Name $MachineName -Backup $machineBackup |
    Sort-Object CreationTime -Descending

# Find the most recent point not marked Infected or Suspicious
$lastClean = $allPoints | Where-Object {
    $_.MalwareStatus -notin @("Infected","Suspicious")
} | Select-Object -First 1

if ($lastClean) {
    Write-Host "Last clean restore point for $MachineName :"
    Write-Host "  Date:   $($lastClean.CreationTime)"
    Write-Host "  Status: $($lastClean.MalwareStatus)"
} else {
    Write-Host "WARNING: No clean restore points found for $MachineName"
    Write-Host "All $($allPoints.Count) restore points are flagged."
    Write-Host "Check the detection timeline and consider restoring from offsite copy."
}

Disconnect-VBRServer

Trigger SureBackup Against a Specific Restore Point

param(
    [Parameter(Mandatory)][string]$MachineName,
    [Parameter(Mandatory)][DateTime]$RestorePointDate,
    [string]$VBRServer = "vbr-server.domain.local",
    [string]$SureBackupJobName = "SureBackup-MalwareResponse"
)

Connect-VBRServer -Server $VBRServer

# Find the backup containing this machine
$machineBackup = Get-VBRBackup | Where-Object {
    (Get-VBRBackupObject -Backup $_).Name -contains $MachineName
} | Select-Object -First 1

if ($null -eq $machineBackup) {
    Write-Error "No backup found for '$MachineName'"
    Disconnect-VBRServer
    exit 1
}

# Get the specific restore point using the correct cmdlet
$targetPoint = Get-VBRObjectRestorePoint -Name $MachineName -Backup $machineBackup |
    Where-Object { $_.CreationTime.Date -eq $RestorePointDate.Date } |
    Sort-Object CreationTime -Descending |
    Select-Object -First 1

if ($null -eq $targetPoint) {
    Write-Error "No restore point found for $MachineName on $($RestorePointDate.Date)"
    Disconnect-VBRServer
    exit 1
}

Write-Host "Target restore point: $($targetPoint.CreationTime) | Status: $($targetPoint.MalwareStatus)"

# Get the SureBackup job
$vsbJob = Get-VSBJob -Name $SureBackupJobName

if ($null -eq $vsbJob) {
    Write-Error "SureBackup job '$SureBackupJobName' not found. Create it first in the VBR console."
    Disconnect-VBRServer
    exit 1
}

# Start the SureBackup session
Write-Host "Starting SureBackup verification for $MachineName..."
$session = Start-VSBJob -Job $vsbJob

# Wait for completion
do {
    Start-Sleep -Seconds 30
    $session = Get-VSBSession -Id $session.Id
    Write-Host "  Status: $($session.State) at $(Get-Date -Format 'HH:mm:ss')"
} while ($session.State -eq "Working")

# Get per-VM task results
$tasks = Get-VSBTaskSession -Session $session |
    Where-Object { $_.Name -eq $MachineName }

Write-Host ""
Write-Host "SureBackup Result for $MachineName :"
Write-Host "  Overall Session: $($session.Result)"

foreach ($task in $tasks) {
    Write-Host "  VM Task: $($task.Name) | Result: $($task.Status)"
    if ($task.Details) {
        Write-Host "  Details: $($task.Details)"
    }
}

# If SureBackup passed, offer to mark the restore point as clean
if ($session.Result -eq "Success") {
    Write-Host ""
    Write-Host "SureBackup passed. The restore point at $($targetPoint.CreationTime) is verified clean."
    Write-Host "Run Set-VBRObjectRestorePointStatus to mark it clean in VBR if your investigation confirms no malware."
} else {
    Write-Host ""
    Write-Host "WARNING: SureBackup did not pass. Do not use this restore point for production recovery."
    Write-Host "Go back to the previous restore point and repeat the process."
}

Disconnect-VBRServer

Mark a Machine Clean via PowerShell

param(
    [Parameter(Mandatory)][string]$MachineName,
    [Parameter(Mandatory)][string]$Reason,
    [switch]$IsFalsePositive,
    [switch]$ExcludeFromFutureScans,
    [string]$VBRServer = "vbr-server.domain.local"
)

Connect-VBRServer -Server $VBRServer

$obj = Get-VBRMalwareDetectionObject |
    Where-Object { $_.Name -eq $MachineName } |
    Select-Object -First 1

if ($null -eq $obj) {
    Write-Error "Machine '$MachineName' not found in malware detection objects."
    Disconnect-VBRServer
    exit 1
}

Write-Host "Marking $MachineName as clean."
Write-Host "  Reason: $Reason"
Write-Host "  False positive: $IsFalsePositive"
Write-Host "  Exclude from future scans: $ExcludeFromFutureScans"

$params = @{
    Object = $obj
}
# Log the reason separately - the cmdlet does not accept a Comment parameter
Write-Host "  Reason logged: $Reason"

# If false positive, mark ALL related restore points clean
if ($IsFalsePositive) {
    $params['MarkAllRestorePoints'] = $true
    Write-Host "  All affected restore points will be marked clean."
}

# Optionally exclude from future malware scans
if ($ExcludeFromFutureScans) {
    $params['ExcludeObjectFromDetection'] = $true
    Write-Host "  WARNING: Machine will be excluded from all future malware scans."
}

Set-VBRMalwareDetectionObjectAsClean @params

Write-Host ""
Write-Host "Done. $MachineName has been marked clean."
Write-Host "Document this action in your incident record."

Disconnect-VBRServer

7. Putting It All Together: The Detection to Verified Recovery Loop

Here's the sequence that ties all of this together as an operational workflow rather than a collection of individual features.

The proactive investigation feature in v13 automates the middle steps for you when detections fire. It can automatically trigger a Scan Backup and automatically mark clean if nothing is found. Configure it in the main menu, Malware Detection, and set up the proactive investigation schedule. That handles your false positives overnight without anyone having to manually work through the queue.