{"domain":"storage-san-attack","category":"storage","tool_count":13,"guide_count":1,"mitre":["T1552-Unsecured Credentials","T1021-Remote Services","T1486-Data Encrypted for Impact","T1530-Data from Cloud Storage Object","T1213-Data from Information Repositories"],"keywords":["SAN","NAS","iSCSI","Fibre Channel","FCoE","NFS","SMB","CIFS","S3","object storage","NetApp","Dell EMC","Pure Storage","QNAP","Synology","TrueNAS","MinIO","NDMP","SMI-S","ONTAP"],"last_reviewed":"2026-07-26"}
test-cases.md — Structured test case templates (12 cases covering enumeration, unauthenticated access, exploitation, vendor abuse, and ransomware scenarios)
guides/storage-san-attack-playbook.md — Comprehensive playbook: storage taxonomy, vendor recon matrix, real-world incidents (DeadBolt, eCh0raix, Capital One S3, Tesla AWS S3), lab setup, and defensive hardening
Summary
This skill targets the storage fabric underlying enterprise data — block (SAN), file (NAS), and object storage systems — and the management planes that govern them. It covers protocol-level attacks against iSCSI/Fibre Channel/NFS/SMB, vendor appliance exploitation (NetApp ONTAP, Dell EMC, Pure Storage, QNAP, Synology, TrueNAS), object storage abuse (AWS S3, MinIO, Ceph RGW, Azure Blob, GCP Cloud Storage, OpenStack Swift), and the ransomware patterns that have made NAS appliances a top-tier target since 2021.
"Empty root MySQL password" / "odat booleans all true"
If you are attacking a SQL listener, that is database-attack. If you are attacking the storage array underneath the database, that is storage-san-attack. In real engagements, both often apply (a database may sit on an iSCSI LUN exported by a NetApp array).
vs. cloud-native-vuln-research
Dimension
storage-san-attack
cloud-native-vuln-research
Objective
Pentest a deployed storage system for misconfig, weak creds, exposed surface
Discover 0-day/CVE in cloud-native software (k8s, container runtimes, IaC)
If the task is "find CVEs in containerd," use cloud-native-vuln-research. If the task is "test the customer's QNAP NAS for DeadBolt-style exposure," use storage-san-attack.
vs. cloud-security
cloud-security covers the broader cloud posture (IAM, VPC, KMS, monitoring). This skill narrows to storage protocols and appliances regardless of whether they live on-prem (NetApp FAS) or in cloud (AWS S3, Azure Blob). When attacking S3 specifically, use this skill; for broader AWS account review, use cloud-security.
Use Cases
iSCSI target discovery and LUN access — Discover sendtargets, log in without authentication, mount LUNs outside of any filesystem-level access control, read raw blocks from disk images that may contain databases, VM images, or secrets
Fibre Channel zoning bypass — Spoof WWNs, abuse permissive zoning, perform name-server spoofing and FSPF route poisoning on a SAN fabric
NFS no_root_squash exploitation — Enumerate exports via showmount -e, exploit UID spoofing, write SUID binaries or SSH authorized_keys to root-squashed vs no-root-squashed exports, bypass NFSv3 filesystem trust
SMB share access and relay — Enumerate shares via null session, test SMB signing configuration, perform NTLM relay (ntlmrelayx) against storage appliances, abuse Kerberos constrained delegation when storage services are domain-joined
S3 bucket enumeration and ACL/policy abuse — Enumerate public buckets (lazys3, S3Scanner, slurp), abuse permissive ACLs, escalate via over-privileged IAM role assumption, extract credentials from public URL patterns (https://s3.amazonaws.com/bucket/)
NDMP backup tape pilfering — Connect to NDMP daemon on port 10000, abuse cleartext authentication, read backup content, extract embedded database or VM credentials from backup streams
SMI-S / SNMP enumeration — Enumerate storage topology via SMI-S WBEM/CIM, abuse read-write SNMP community strings to extract LUN mappings and administrator contacts
NAS ransomware assessment — Evaluate a QNAP/Synology/TrueNAS deployment for DeadBolt-style or eCh0raix exposure: internet-facing admin console, default credentials, missing 2FA, exposed SMB/NFS to WAN
Object storage ransomware assessment — Test S3 Object Lock / versioning configuration, evaluate whether an attacker with one IAM role can mass-encrypt or mass-delete objects across buckets
Storage appliance lateral movement — Pivot from a compromised host to a storage array using harvested credentials, then read VM disk images or database backups to escalate further
DRBD / replication abuse — Intercept or inject into DRBD replication streams, abuse rsync-over-SSH trust to become the primary for a replicated storage cluster
Core Tools
Tool
Purpose
Command Example
nmap + NSE
Service discovery, iSCSI/NFS/SMB/SNMP enumeration via built-in NSE scripts
Multi-cloud object storage client — bucket enumeration against MinIO/Ceph RGW/Wasabi/B2/AWS S3; rclone for sync abuse
mc alias set eng http://10.0.0.5:9000 REPLACE_WITH_YOUR_KEY REPLACE_WITH_YOUR_SECRET; mc ls eng/; rclone copy :s3,provider=Minio,endpoint=http://10.0.0.5:9000:/bucket ./out
S3: enumerate buckets by name brute-force, list object counts via ListObjects, fingerprint provider via response headers (Server: AmazonS3, Server: MinIO, Server: Ceph)
Test vendor default credentials against admin interfaces (admin/admin, nasadmin/nasadmin, root/admin on Synology, admin/admin on QNAP)
Test SMB null session and anonymous LDAP bind where storage is domain-joined
Test S3 anonymous (no-signed-request) access on every discovered bucket
Test SNMP read-write community strings (private, readwrite) against storage MIBs
Brute-force iSCSI CHAP secrets via custom scripts against iscsiadm login attempts
Test NDMP cleartext auth (password field left blank, or known default backup/backup)
Phase 4: Exploitation
iSCSI unauth: log in to a target without CHAP, mount the LUN locally, run fdisk -l, mount the filesystem read-only, read VM images and database files directly from disk
NFS no_root_squash: write SUID shell, write authorized_keys to a user's .ssh/, drop cron jobs in /etc/cron.d/
SMB relay: use ntlmrelayx to dump SAM from a domain-joined Windows NAS, or pivot to other SMB hosts
S3 object retrieval: download all objects, search for embedded secrets (access keys, DB passwords, private SSH keys)
Vendor API: pull vserver credentials from NetApp, pull host IQNs from Dell EMC, harvest API tokens from Pure Storage users
NDMP: connect and request backup stream dump, parse for embedded database or VM credentials
Demonstrate ransomware-style impact: write a marker file across an SMB share, mass-encrypt a bucket of test objects (engagement scope permitting)
Pivot from storage to the workloads it backs: a database backup on NDMP tape may contain live credentials; a VM image on an iSCSI LUN may contain authorized_keys
Harvest credentials from appliance configuration: NetApp vserver services name-service often caches LDAP binds; Synology DSM stores S3 sync credentials in /etc/synology/s3.conf
Cover tracks per engagement scope: most appliances log to a syslog target; coordinate with the customer's SOC to validate detection
Defense Perspective
Defense Measure
Description
Priority
Block-level encryption
LUN-level encryption (NetApp NVE, Pure Purity Encryption); encrypts at-rest in the array
CRITICAL
iSCSI CHAP mutual auth
Bidirectional CHAP with strong secrets; never expose LUNs without authentication
Mounting iSCSI LUNs read-write on production — catastrophic data corruption risk. Always mount read-only during an engagement, and coordinate any read-write test with the customer's storage admin
Treating NFSv3 no_root_squash as a minor finding — it is full root compromise of every file on the export and frequently the entire host if writable exports overlap with system directories
Ignoring SMB signing configuration — even if you cannot relay, missing signing is a free downgrade-attack primitive that affects every host the NAS can reach
Bucket enumeration without considering region — AWS S3 returns different results for region-scoped vs global calls; always test both --region us-east-1 and the bucket's home region
Skipping vendor default credentials on appliances — QNAP, Synology, older NetApp, and Dell EMC deployments ship with well-known defaults; missing these is an avoidable miss
Forgetting NDMP — backup daemons are often forgotten, exposed on the LAN, and contain the most valuable data on the storage estate (full backups with live credentials)
Ransomware simulation without explicit authorization — even writing a marker file is a high-impact action; always have a separate authorization for ransomware-style tests
Dismissing SNMPv2c as low risk — read-write community strings on storage appliances allow LUN reassignment, fabric reconfiguration, and credential extraction; treat as CRITICAL
Testing Fibre Channel fabrics without coordination — fabric attacks (WWN spoofing, FSPF poisoning) can split a production SAN; always test on a dedicated fabric or in a maintenance window
Integration with Other Skills
database-attack: A database may sit on an iSCSI LUN exported by a NetApp array; compromise the array and you own the database at the block level, bypassing DB authentication entirely
ad-ldap-attack: Domain-joined NAS appliances (NetApp, Dell EMC, Synology) participate in AD authentication; AD compromise enables storage compromise and vice versa
cloud-security: S3 attacks here complement broader AWS/Azure/GCP posture review; coordinate to avoid double-counting findings
password-attack: Vendor appliances often share credentials across an estate; spray findings across NetApp/Dell/Pure instances
privilege-escalation: Storage access (especially iSCSI LUNs containing /etc/shadow or Windows SAM) is a reliable local privesc primitive
ransomware-triage (if present): NAS-targeting ransomware (DeadBolt, eCh0raix) and S3 mass-encryption scenarios feed into incident response playbooks
Storage attacks carry elevated legal risk because storage systems hold regulated data at scale — a single misconfigured S3 bucket can expose millions of PII records, and a corrupted LUN can destroy production databases. Always confirm scope covers the specific storage system, snapshot or unmount production LUNs before any read-write test, and never run ransomware simulation without a separate signed authorization. Evidence (downloaded S3 objects, mounted LUN contents, NDMP tape streams) must be encrypted at rest in the engagement vault and destroyed at the end of the engagement unless retention is explicitly authorized. Coordinate with the customer's storage administrator before any vendor API call that could modify state (vserver modify, storage volume destroy, s3:DeleteObject).
Storage Attack Surface Taxonomy
Storage attacks divide along three protocol families. Each family has distinct attack primitives, defensive boundaries, and incident patterns.
Block (SAN) — iSCSI, FC, FCoE, NVMe-oF, SAS
Block storage presents raw LUNs to initiators. The attacker's goal is to access a LUN outside of any filesystem-level authorization. Once a LUN is mounted, the attacker sees the raw disk — including deleted files, slack space, and filesystem metadata — bypassing every OS-level control on the host that owns the LUN.
File storage presents a network filesystem with per-file authorization. Attacks target the protocol's authorization model: NFS UID mapping and root squashing, SMB share/NTFS ACLs and signing, AFP guest access. The goal is to read or write files outside of what the user's identity should permit.
Object storage presents a flat namespace accessed via HTTP API with per-request signing. Attacks target bucket policies, ACLs, IAM roles, and URL signing. The goal is to enumerate or access objects without authorization, or to escalate privileges via over-permissive IAM.
Key attacks: bucket name brute-force, ACL bypass, policy escalation, IAM role assumption, URL signing replay, credential extraction from public objects.
Vendor Management Planes
Every storage vendor exposes a management API (NetApp ONTAP REST/ZAPI, Dell EMC Naviseccli/REST, Pure Storage REST, HPE Nimble REST, QNAP QTS web, Synology DSM web, TrueNAS API). These planes are CVE-rich and frequently internet-exposed. Compromise of the management plane yields full control of every LUN, share, and bucket on the appliance.
Initial access: Default credential spray (admin/admin), exploit known CVE (QNAP Photo Station CVE chain, Synology DSM CVE chain), or brute-force 2FA-bypass
Lateral movement: enumerate SMB shares via domain credentials harvested from the appliance, pivot to Windows hosts
Impact: encrypt SMB shares in place, drop ransom note, optionally exfiltrate for double extortion
Persistence: leave a web shell on the appliance (QNAP QTS Apache, Synology DSM nginx) for re-entry
Object-storage ransomware follows a different pattern: an attacker with one over-privileged IAM role can mass-encrypt or mass-delete every object in every bucket the role can reach. The 2019 Capital One breach demonstrated the enumeration phase; subsequent in-the-wild incidents have demonstrated mass-encryption via s3:PutObject with ransomware-encrypted blobs.
See guides/storage-san-attack-playbook.md for a deep dive on each incident and defensive patterns.
Learning Resources
This skill's supplementary files: payloads.md, test-cases.md, guides/storage-san-attack-playbook.md
Related skills: skills/database-attack/SKILL.md, skills/cloud-security/SKILL.md, skills/ad-ldap-attack/SKILL.md, skills/cloud-native-vuln-research/SKILL.md
