Lessons learned from Hacking Team attacker - Part 2

Earlier I posted about HackingTeam's attacker post mortem describing the hack.  I'll keep part two short and sweet since it's a busy day for me on a forensics case.

The attacker notes in his post mortem that much of the data he stole was made possible due to data in backups.  He was able to easily access the backups on the network attached storage (NAS) devices because the iSCSI targets did not require authentication.

Nmap scan report for ht-synology.hackingteam.local (192.168.200.66)
...
3260/tcp open  iscsi?
| iscsi-info:
|   Target: iqn.2000-01.com.synology:ht-synology.name
|     Address: 192.168.200.66:3260,0
|_    Authentication: No authentication required
Nmap scan report for synology-backup.hackingteam.local (192.168.200.72)
...
3260/tcp open  iscsi?
| iscsi-info:
|   Target: iqn.2000-01.com.synology:synology-backup.name
|     Address: 10.0.1.72:3260,0
|     Address: 192.168.200.72:3260,0
|_    Authentication: No authentication required

There are two takeaways here:

1. Always require authentication on your iSCSI targets.  
2. Continuous network monitoring would have discovered the data exfiltration with ease.

Takeaways in detail:
NAS vendors like Synology and QNAP make it too easy to screw up iSCSI authentication with their easy to use administrative interfaces.  This never used to happen in the old days when real systems admins used to have to get involved with the creation of every iSCSI target.  This is a good point to consider - scan your networks for iSCSI (default on TCP port 3260).  During penetration tests at Rendition Infosec, we regularly find open iSCSI ports.  Unfortunately, many have weak or no authentication.

Continuous network monitoring is something we frequently talk about in security, but rarely actually do.  When Rendition Infosec does incident response, we almost always use network monitoring to aid in uncovering the badness that lurks beneath.  One of the things we're looking for are communications to odd devices.  Whether the attacker uses a port forward or a kernel module to connect to the iSCSI device and begin siphoning data, this will stand out like a sore thumb in net flow and connection logs - but only if you are looking.  Recall that the attacker pivoted through an undisclosed embedded device - this is probably not the sort of thing you expect to have an iSCSI connection, especially not if it's transmitting lots of data.

Closing thoughts
Don't pass up this rare opportunity to get a first hand account from the attacker on how the crime was committed.  Examine the post mortem and determine whether your organization would hold up under a similar attack.