iSCSI (Internet Small Computer Systems Interface) is a network protocol that allows computers (known as initiators) to send SCSI commands over TCP/IP networks to storage devices (called targets). It effectively let’s you access remote storage as if it were locally attached.
iSCSI allows you to build Storage Area Networks (SAN’s) using standard Ethernet networks.
Configuring iSCSI Targets on Linux
Install the SCSI target user-space daemon and tools package.
sudo apt install tgt
Next, create a dummy disk.
user@Ubuntu:~$ sudo dd if=/dev/zero of=/mnt/iscsi_target1.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.25272 s, 857 MB/s
Create a configuration file, which includes an iSCSI Qualified Name (IQN) for the target. This is unique to each target, and uses the following format.
iqn.<year-month>.<reverse-domain>:<name>
cat /etc/tgt/conf.d/target1.conf
<target iqn.2026-03.local.bordergate:target1>
backing-store /mnt/iscsi_target1.img
initiator-address 172.16.0.0/16
</target>
Then restart the tgt service.
sudo systemctl restart tgt
Probing the Service
NMap can be used to discover iSCSI services configured without authentication using the iscsi-info NSE script. From the below output, we can see that the service is running on TCP port 3260 and authentication is not required.
nmap -sC -sV 172.16.1.54 -p 3260
Starting Nmap 7.95 ( https://nmap.org ) at 2026-03-23 09:46 EDT
Nmap scan report for 172.16.1.54
Host is up (0.00025s latency).
PORT STATE SERVICE VERSION
3260/tcp open iscsi?
| iscsi-info:
| iqn.2026-03.local.bordergate:target1:
| Address: 172.16.1.54:3260,1
|_ Authentication: NOT required
MAC Address: 08:00:27:04:0A:56 (PCS Systemtechnik/Oracle VirtualBox virtual NIC)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 156.54 seconds
To mount the iSCSI disk, install the open-iscsi package.
sudo apt install open-iscsi
The following commands will list available targets on a remote host, and mount them.
sudo iscsiadm --mode discovery --type sendtargets --portal 172.16.1.54
172.16.1.54:3260,1 iqn.2026-03.local.bordergate:target1
sudo iscsiadm --mode node --targetname iqn.2026-03.local.bordergate:target1 --login
Login to [iface: default, target: iqn.2026-03.local.bordergate:target1, portal: 172.16.1.54,3260] successful.
sudo iscsiadm --mode session
tcp: [1] 172.16.1.54:3260,1 iqn.2026-03.local.bordergate:target1 (non-flash)
Running fdisk will show the virtual disk appears as /dev/sdb on the initiator system.
┌──(kali㉿kali)-[~]
└─$ sudo fdisk -l
Disk /dev/sda: 80.09 GiB, 86000000000 bytes, 167968750 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd094a0b4
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 167968749 167966702 80.1G 83 Linux
Disk /dev/sdb: 1 GiB, 1073741824 bytes, 2097152 sectors
Disk model: VIRTUAL-DISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
To use the disk, create a file system on the block device and mount it.
┌──(kali㉿kali)-[~]
└─$ sudo mkfs.ext4 /dev/sdb
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 0713a259-c8ff-4ec2-b76a-3a4caf62c5d5
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
┌──(kali㉿kali)-[~]
└─$ sudo mkdir /mnt/iscsi
┌──(kali㉿kali)-[~]
└─$ sudo mount /dev/sdb /mnt/iscsi
┌──(root㉿kali)-[/mnt/iscsi]
└─# mount | grep sdb
/dev/sdb on /mnt/iscsi type ext4 (rw,relatime)
Many file systems, such as EXT4 and NTFS are not designed to allow multiple clients to write to disks at the same time. Doing so many result in data corruption. As such, if your mounting a disk that may already be mounted on other systems, it’s best to open it in read only mode.
sudo mount -o ro /dev/sdb /mnt/iscsi
CHAP Authentication
Challenge Handshake Authentication Protocol (CHAP) authentication can be enabled by adding the incominguser directive into the servers configuration file.
cat /etc/tgt/conf.d/target1.conf
<target iqn.2026-03.local.bordergate:target1>
backing-store /mnt/iscsi_target1.img
initiator-address 172.16.0.0/16
incominguser user Password1234
</target>
Note, the password needs to be between 12-16 characters long. On the initiator system, include the credentials in /etc/iscsi/iscsid.conf.
tail /etc/iscsi/iscsid.conf
node.session.auth.authmethod = CHAP
node.session.auth.username = user
node.session.auth.password = Password1234
You may need to then clear stored credentials and rediscover the iSCSI target.
sudo iscsiadm -m node -o delete
sudo iscsiadm -m discovery -t st -p 172.16.1.54
172.16.1.54:3260,1 iqn.2026-03.local.bordergate:target1
sudo iscsiadm --mode node --targetname iqn.2026-03.local.bordergate:target1 --login
Login to [iface: default, target: iqn.2026-03.local.bordergate:target1, portal: 172.16.1.54,3260] successful.
NMap does have an NSE script to perform iSCSI CHAP brute force (iscsi-brute), unfortunately I couldn’t get it to work against the targets I tried. It’s still useful to know how to configure CHAP authentication, in case you are in a position you can extract a iscsid.conf configuration file from a system that contains credentials.
In Conclusion
It’s common to see iSCSI shares configured without authentication on internal pentests. Implementing CHAP authentication can make it more difficult for an adversary to access the contents of the drives, although they may be able to brute force, or intercept the credentials.