Penetration Testing Explained, Part I: Risky Business. In most of the security standards and regulations that I’ve been following there’s typically a part titled Risk Assessment.
You can find this requirement in HIPAA, PCI DSS, EU GDPR, NIST, and SANS, to reel off just a few four- or five-letter abbreviations. What is risk assessment? It’s the process by which you decide where the vulnerabilities are in your system, the likelihood of the holes being exploited, and then the potential impact on your business. The Art of Risk Assessment If you want a more formal definition, here’s how the folks at the Payment Card Industry (PCI) define it: Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential) based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources to countermeasures so as to minimize total exposure. Risk assessment, though, is more than just an item you check off after chatting with your IT admins. Penetration Testing Explained, Part II: RATs! Remote Access Trojans or RATs are vintage backdoor malware.
Even though they’ve been superseded by more advanced command-and-control (C2) techniques, this old, reliable malware is still in use. If you want to get a handle on what hackers are doing after they’ve gained access, you’ll need to understand more about RATs. A RAT’s Tale RATs came on the scene in the late 1990s or early aughts, and may have been first used as administrative tools—hence its other name, Remote Administrative Tool. But it quickly evolved backdoor capabilities and became stealthier and deadlier. BO2K, SubSeven, and Netbus are just a few of the more common critters in the RAT world — see this Microsoft TechNet article for a complete rundown. So why look at them? Penetration Testing Explained, Part III: Playing with RATs and Reverse Shells. Last week I broke into a Windows 2008 server and inserted a remote access trojan or RAT.
Don’t call security, I did this in a contained environment within virtual machines. To continue on with my pen testing experiment, in this post I’ll explore a few basic steps and techniques used by hackers after they’ve entered a system. Where Am I? One of the first tasks for a hacker is to map out the surrounding terrain in the victim’s environment. Remember: the RAT is running on some remote computer, and the only information the hacker has is a single public IP address.
As a practical matter, you’d want to know what other computers are connected to the target. One quick baby step is simply to look at the ARP tables. The address resolution protocol or ARP is used to map IP addresses to MAC addresses. Exploring the local network with arp -a. Anyone can view the tables by entering arp -a from a command line in Windows (and Linux).
And that’s just what I did. Reverse Shell Game. Penetration Testing Explained, Part IV: Making the Lateral Move. You can think about the post-exploitation part of penetration testing as an army or rebel force living off the land.
You’re scrounging around the victim’s website using what’s available — shells, networking utilities, berries, poorly protected password files, etc. Kidding about the berries, but the idea is to import as little malware as possible and leverage what you find for more exploration and new attacks. This whole topic goes under the name of “malware-less” hacking, which is much harder to detect than old-school techniques. Penetration Testing Explained, Part V: Hash Dumping and Cracking. In the last post in this series, I guessed a local password and then tried various ways to move laterally within my mythical Acme network.
But what happens if you can’t guess the password? In my pen testing scenario, there’s a beer motif in all the naming of the servers and the local admin passwords. It’s not completely unheard of for busy IT people to sacrifice security for convenience. “I’m on the miller server, so I know my admin password is admin-miller.” Hackers of course are ready to jump on these weaknesses. But let’s say you land in an environment where you’re inspired password guessing is not succeeding. I’ve been writing about Pass the Hash (PtH) on and off over the last year. There Be Hashes On a Windows system, plaintext passwords are never stored. Penetration Testing Explained, Part VI: Passing the Hash. We’re now at a point in this series where we’ve exhausted all our standard tricks to steal credentials — guessing passwords, or brute force attacks on the hash itself.
What’s left is a clever idea called passing the hash or PtH that simply reuses a password credential without having to access the plaintext. Mimikatz Remember the simple test environment I had set up? I have a Windows domain with two servers for the mythical Acme company with its beer-based server naming scheme. Playing the part of the pen tester, I landed on employee Jane’s server, initially using a RAT, and then at some point was able to pop a shell. In our last post, I showed you how to dump the local user hashes with fgdump. Let’s now meet mimikatz, developed by Benjamin Delpy. Mimikatz is an amazingly powerful tool that probes the lsass process for hashes, and has the ability to run programs under these hash credentials. You can download the mimikatz binary from github. The software has its own mini command language. Penetration Testing Explained, Part VII: Exfiltration and Conclusions. In this series of posts, I covered ideas to get you started using basic testing software to find security vulnerabilities.
There are more advanced tools, such as Metasploit, which lets you speedily try different hacking scenarios, but many of its principles are based on what I’ve already written about.