Lab: Defender for Storage Malware Scanning and Sentinel

Deploy malware scanning for uploaded blobs and correlate post-verdict reads in Sentinel with Bicep, analytics rules, a workbook, and safe simulations.

Source maintenance reviewed September 4, 2026: this updated source passed its offline and CI checks. Historical tenant evidence below retains its original dates; no fresh tenant deployment or detection result is asserted here.

Overview

This lab enables Defender for Storage malware scanning, routes the resulting security evidence into Sentinel, and validates detection and investigation paths with deliberately bounded test scenarios.

Start Here

  1. Read the companion article for the evidence model and tested detection behavior.
  2. Use the canonical GitHub repository for prerequisites, deployment, validation, troubleshooting, and cleanup.
  3. Run only the documented safe simulations in an isolated lab subscription.

Never upload real malware. The lab uses safe test artifacts and defensive validation paths.

The current uploader defaults to a read-only ownership preview:

./attacks/upload-eicar.sh
# Upload the harmless test pair only after reviewing the verified target.
./attacks/upload-eicar.sh --execute

It requires the active deployment manifest and exact live group/account/ingest-container IDs and owner metadata. Older manifests/containers must be refreshed by the reviewed deployment; arbitrary storage overrides are refused. Random blob names and service-side no-overwrite conditions protect existing files. The script does not fabricate a scan verdict or remove an earlier successful upload if a later upload fails.

Rule 5 Validation Boundary

The included scripts do not automate Rule 5. Azure can reject completely unauthenticated garbage before it reaches StorageBlobLogs; a few bad SAS strings are therefore not a reliable test. Reproduce the correlation only with a disposable, authenticated but under-privileged principal that generates authorization failures, followed by successful reads from the same egress IP. Remove that identity afterward.

Historical companion-article evidence records a successful live Rule 5 incident created with this controlled method. That evidence does not turn the public attack scripts into a deterministic Rule 5 generator.