Skip to content

SYSTEM Cited by 1 source

Amazon GuardDuty Malware Protection

Definition

Amazon GuardDuty Malware Protection is a feature of Amazon GuardDuty that scans backup recovery points and EC2 volumes for malware without requiring agents on the workload.

In cyber-resilience designs, GuardDuty Malware Protection is the second layer of the multi-layer validation pipeline — providing AWS-native malware scanning on restored volumes during the validation stage.

Verbatim from the canonicalising source:

"AWS native — Amazon GuardDuty Malware Protection — Malware scanning on restored volumes" (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Two scanning modes

GuardDuty Malware Protection supports two scanning modes relevant to cyber-resilience:

Mode 1: Backup recovery point scanning

Scans backups in AWS Backup vaults without restoring them first. The scan happens against the backup contents, surfacing malware before the backup is used for restore. This is referenced in the post's reference to "AWS Marketplace partner solutions" providing "content-level ransomware scanning inside backup contents, without requiring a full restore first" — though the AWS-native version of this capability is part of GuardDuty Malware Protection.

Mode 2: EBS volume scanning

Scans EC2 EBS volumes (live or restored) for malware. In cyber- resilience, this is used inside the IRE against newly restored volumes:

  1. Recovery point candidate is restored into IRE.
  2. GuardDuty Malware Protection scans the resulting EBS volume(s).
  3. Malware findings are surfaced as GuardDuty findings; the restore candidate is rejected if findings appear.

The canonicalising source's checklist:

"Enable AWS Backup Restore Testing on a regular schedule, and enable Amazon GuardDuty Malware Protection for backup and volume scanning."

The "backup and volume scanning" phrase covers both modes.

What it catches

Malware Protection signatures cover:

  • Known ransomware — encryption tools, common ransomware families.
  • Known malware — trojans, backdoors, droppers.
  • Indicators of compromise (IoCs) — file patterns associated with known threat actors.
  • Suspicious file behaviours — files with characteristics associated with malicious software.

What it doesn't catch

Per the canonicalising source's framing of why multi-layer validation is needed:

"For threats that have been present in the environment for some time, a malware scan isn't enough because the attacker might have modified legitimate code, configuration, or data in ways that look normal to a scanner."

Malware Protection's miss class:

  • Modifications to legitimate code that don't introduce malware signatures.
  • Modified configuration (e.g. an attacker disabled logging via a config change — no malware involved).
  • Data integrity violations (e.g. transactions inserted into a database — looks like normal data to a malware scanner).
  • Long-dwelling adversaries that have established persistence through legitimate channels.

This is why Malware Protection is one layer of five in the validation pipeline, not a sole reliance.

Composition with the validation pipeline

Layer Mechanism Catches
AWS Backup Restore Testing Recoverability + custom hooks Backup is readable + workload-specific consistency
GuardDuty Malware Protection Signature-based malware scan Known ransomware / malware on volumes
AWS Marketplace partner scanners Content-level scanning of backup contents Pre-restore detection of malware / IoCs
Workload-specific checks Database consistency / application invariants / config diff Modifications invisible to scanners
Log / audit review CloudTrail + workload logs Unexpected identity / config changes

GuardDuty Malware Protection covers its slice well but isn't sufficient alone — the validation pipeline's conjunctive acceptance criterion ("Both AWS-native validation and workload-specific validation should pass") ensures multiple layers must agree.

Operational considerations

Coverage

Malware Protection coverage typically includes:

  • EBS volumes attached to EC2 instances.
  • Backup recovery points stored in AWS Backup vaults.
  • S3 objects (newer S3 Malware Protection capability).

Scan triggers

In cyber-resilience designs, scans typically trigger:

  • On restore — automatic scan of newly-restored volumes in IRE.
  • On backup creation — scan recovery points as they're written to the vault (proactive detection).
  • On schedule — periodic re-scan of stored backups for newly- signature-able malware.

False-positive handling

Malware Protection findings may be false positives (e.g. signatures matching dual-use tools). The cyber-resilience workflow should distinguish:

  • High-confidence findings → reject the candidate.
  • Low-confidence findings → escalate to manual review by the approver.

This is part of why human approval gates the workflow — false positives need expert judgment.

Generalisation beyond AWS

Equivalent malware-scanning-on-backup services:

  • Microsoft Defender for Cloud / Azure Backup malware scanning — equivalent functionality in Azure.
  • GCP Security Command Center + Cloud DLP — broader threat detection that includes malware patterns.
  • Third-party — Veeam, Cohesity, Rubrik with built-in malware scanning of backups.
  • Open source — ClamAV, YARA rules.

The structural property: automated malware scanning of backup recovery points and restored volumes, integrated with backup infrastructure.

Seen in

Last updated · 542 distilled / 1,571 read