You can read the previous installments in our blog.
But, to recap: in Part 1, we demonstrated how to build the con for our fictional target company Contoso. In Part 2, we set the hooks for our targets and got zombies on the line. In Part 3, we gathered information from our hooked targets and started exploiting that data.
In this episode, we will discuss how we can pivot and hop further inside the internal network and how we can foolproof our encounters to conduct a professional pen test within a given scope and time frame.
Based on our previous work, we have a slew of hooked browsers and we have penetrated the first level of defenses. At this point, we want to leverage our hooked browsers to pivot and hop inside the network.
We start off by identifying the computers in the same network of the hooked browsers. Since we already have the browser’s internal IP (refer to part 3), we run our scan against its class C network using the ping sweep modules. For firefox, we use the “network/Ping Sweep” module which does not require user interaction, and for other browsers we use the “network/Ping Sweep Java”.
Additionally, we fingerprint common appliances on the same network of the hooked browser using the “network/Internal Network Fingerprinting” module. This module will try to enumerate common appliances (printers, routers, media servers, ...etc) on some default IP address using pre-defined file signatures.
After we have identified some live IPs, we start scanning those IPs for open ports. Using the “network/Port Scanner” module, we can port scan internal IPs of a hooked browser (Firefox, and Chrome only). The module uses WebSockets and HTML5 techniques to conduct the scan.
To further investigate our internal targets, we can run a DNS enumeration scan on the internal network via the “Network/DNS Enumeration” module. The DNS enumeration module uses dictionary and timing attacks to identify common internal domain names such as (intranet, mail, print, ...etc). This can be very helpful in identifying internal resources.
Now that we have a good understanding of the internal network, the last step is to scan internal applications for further vulnerabilities. Using the “Tunneling Proxy” extension, we can chain our browser, a web vulnerability scanner such as Burp Suite and the hooked browser in a proxy chain. This video by Michele “antisnatchor” Orru best describes how this can be achieved.
We can even craft and send raw requests proxied via a hooked browser using the Rider extension tab. This allows us to conduct convoluted attacks on the internal web servers.
It is worth mentioning, we can do more pivoting and hopping by leveraging the meterpreter shells we have on some non-important hosts and the compromised test server (see part 3) but that is beyond the scope of this text.
Now that we have fully penetrated our target, we want to point out some of the proofing tips that will help us keep the pen test clean and professional.
The first thing we need to take care of is preventing backfire from disgruntled employees and/or target sys admins. The last thing we want is to get hacked by our customers! To secure our own perimeter, we take a few precautions:
- Limit the admin UI interface of BeEF to the internal IPs only that we actually use to administer BeEF. This can be achieved from the main config.yaml file by setting the “permitted_ui_subnet” to match the administration internal subnet.
- Setup firewall rules on the BeEF server to block all external access except for the web port, metasploit payload delivery port and browser autopwn port (if applicable).
For larger numbers of hooked browsers, the performance of the default underlying DB driver (i.e. SQLite) drops dramatically leading sometimes to unexpected behaviours. If you are planning to have a large number of hooked browsers, use BeEF in MySQL DB mode. This can be configured in the main config.yaml file under “database:driver:” section. Also, changing the update timeout value to 1-2 seconds in updates.js (based on the connection speed) might give a performance boost.
It goes without saying that we need to have our written authorization of the penetration test. What is sometimes missing are small details that might cause problems. The following are examples of sensitive “grey” interactions that should be explicitly declared in the scope and agreed upon a priori:
- Sending buzzing phishing emails (especially to or about C-Level execs).
- Capturing employees personal information and using it to gain access to their corporate machines.
- Extracting wireless keys from corporate machines given that there might be some personal wireless keys on laptops or BYOD-style devices.
In order to keep the scope of the pen test from creeping to personal grounds, we can take some more precautions:
- Limit the hooking subnets to only the IP ranges of the target company to prevent accidental or out of scope hooking of browsers. However, this will severely limit smartphones hooking as they will most likely get hooked via their 3G/4G interface.
- Limit the hooking machines to only ones with a predefined set of referrer URLs that we use. This is a weak limitation but might be handy in case of mobile devices.
- Do not save exported wireless keys that do not belong to the corporate wireless.
- Do not save or use private photos and/or videos exported from the users’ profiles or harvested in the recon phase, as this is not corporate related and probably off limits.
Now that we have successfully penetrated the perimeter, hopped inside the internals of the network, and secured ourselves from backfire and scope creep, we are ready to write the report focusing on how our client will be able to fix the issues through which we were able go gain this access.
Special thanks to Heather Pilkington for helping me out through this series, Michele Orru for his insightful comments, and all BeEF team for their great support!