My book club has moved on from Practical Packet Analysis (great read – highly recommend) to The Hacker Playbook 3. I plan to write up notes on each chapter, mostly for my reference. These will likely be mostly pictureless brain dumps, but may give some useful info. So here goes…
Disclaimer – hacking is illegal, read CFAA, don’t go to jail, etc.
Author Peter Kim recommends doing the hands-on work, including pushing scripts and code to Github. That’s a little scary to think about (people will see!), but a good idea. So I’ve set up a repository on my Github for THP3 stuff. The blog posts/notes will serve as more of my record since I’m not sure how much script writing I’ll actually be doing.
Remember hacking is illegal, disclaimers, etc. Big thing here is get WRITTEN permission and make sure the powers that be know what’s going on. A side note here is that this may include third parties such as cloud vendors. Luckily there are lots of legal places to practice hacking and pen testing. I have a bunch that I like, but that’s a different post.
Interesting comparison of pen testing versus red teaming. I see the need for both, but I suspect red teams as described are beyond the capabilities of most orgs. Kim also mentions showing value back to the company. This seems to be something that can be a struggle in cybersecurity in general. It’s hard to put value on something being avoided, but it’s something that needs to be done.
Lots of good background in this chapter, but the bulk was getting set up. Kim recommends setting up an external server. I’m definitely more comfortable using a VM, but I decided the practice would be good for me. I went with an Amazon Lightsail server running Ubuntu. Doing this with the recommended specs will probably run about $5/month. You could opt to set everything up using VMs, but I wanted the practice and learning at least a little about AWS can only be good for me.
Spinning up the instance was simple and only took a few minutes. You can access the server through a CLI setup in the browser or use an SSH client. I’ve mostly used the CLI option so far, but I’ve got Putty downloaded to setup the SSH option. Kim does note the need to set up iptables for your VPS (virtual private server). This is a firewall utility built into Linux. I want to get into this more, but for now I’m using the firewall manager through AWS. I need to find out more about how the 2 will work together or fight before I start with iptables. Plus since I can access the AWS firewall from the dashboard, I’m less likely to fork my access. I’m making notes of things I need to follow-up on, but I want to stay on task with the material.
Installing The PenTester’s Framework was straightforward. There are lots of instructions on how to do that, so I’m not going to get into that here.
I will note that a lot of the tools that are talked about the rest of the chapter are included in PTF, so you don’t necessarily need to install them separately. I’ve worked with PTF a little, but I’ve done more in Kali. I’m looking forward to working with both as I work through the book. Kim talks about having a process to repeatedly setup machines and mentions the possibility of running Kali in Docker on AWS. This is something I’ll need to work on later, but it was simple to spin up the instance and get PTF loaded. I have a process for when I start a new Kali VM to install the non-standard tools that I like, so I’ll add tools to that process as appropriate.
Some of the tools mentioned…yes, I’m being lazy and not doing the links.
- Metasploit – it’s Metasploit, lots of info out there
- Cobalt Strike – license is expensive, so I’m waiting to do a trial for when I know I’m going to have dedicated time to spend. Armitage seems to be a relative and is pretty straightforward.
- PowerShell Empire – needs a real cert to work best. More on this later.
- dnscat2 – creates an encrypted command and control channel, should be fun to play with. Has turned into a pain, but I’m sure will be a good learning experience.
- p0wndedShell – C# PowerShell host app that isn’t really PowerShell. Just installed, no labbing yet.
- Pupy Shell – run Python on all the things without installing Python. Just installed, no labbing yet.
- PoshC2 – command and control thing in PowerShell to help hack things. Just installed, no labbing yet.
- Merlin – do cool things with HTTP/2. Just installed, no labbing yet.
- Nishang – use PowerShell for red team stuff. Just installed, no labbing yet.
Getting most of these installed and testing them out was straightforward. I’m waiting on Cobalt Strike, so other than thinking it looks cool, no real thoughts there. Getting a cert installed for PowerShell Empire was the biggest hurdle. This was more because it seemed daunting than anything else.
Really brief summary of getting Empire going (at least to the level I need right now).
- Get a domain name. I picked up a cheap one from NameCheap.
- Set your AWS instance to a permanent IP.
- Install domain name on AWS instance. This post from Joshua Miller had great instructions using NameCheap. Note – you manage DNS in AWS from the overall dashboard, not the instance dashboard.
- Make sure your domain name was connected by navigating by name rather than IP. This may take some time, but it happened within minutes for my instance.
- Get a trusted cert and install it on AWS instance. This post from Black Hills Info Sec had a great walkthrough. Probably should make a note of the cert path (/etc/letsencrypt/live/[domain]/fullchain.pem).
- Check and make sure your domain name now works as https.
- Wonder why your domain name isn’t working as https.
- Keep wondering…
- Facepalm when you realize you forgot to adjust the firewall to allow https.
- Laugh at yourself for forgetting to adjust the firewall and remind your book club that they might need to let https through the firewall of their VPS.
And laugh again when Ian Coldwater tweets about breaking the Internet by leaving Intercept on. Because you’ve done that at least once this week and you’ve accepted breaking the Internet is going to happen regularly when you’re doing this stuff. Just remember to check your stuff before panicking and yelling at your ISP.
The other bit of oddness was getting setup for dnscat2. The author used GoDaddy, so I had to do some experimenting for Namecheap. I got my domain added under the personal DNS server (with ns1.[IP] and ns2.[IP]) and nameservers (ns1.[url] and ns2.[url]). Note that to get your personal DNS servers to show in the dashboard on Namecheap, you need to do a search – it doesn’t show up automatically, so I kept thinking I screwed something up. I wasn’t entirely confident in what I had done, so I did dome digging and found good references from iagox86 (the tool’s author) and The Subtlety. I was able to check and make sure the setup was working. I ran into another error – address in use – when I ran the script to start dnscat2.
After some digging, it seems there can be an issue with Ubuntu and systemd-resolved. Looking over some things – a StackExchange about the issue and the man page for systemd-resolved, I think this is causing a conflict with DNS resolution. You can check the processes running with
netstat -plnt to see exactly what the issue is. Killing the process just using kill didn’t work, so I tried stopping that process (probably not great idea), but it let dnscat2 work. And it’s easy enough to start and stop the process (
systemctl start/stop systemd-resolved). So I got the server working, but then the client timed out. More head banging…but luckily someone in the book club had dealt with this fix and had a write up – thanks Vext! I also found a walkthrough for using dnscat2 with PowerShell from Black Hills Information Security that I want to file for future reference. Basically you have to add the
--no-cache option when setting up the server. Based on the posts from Vext and Black Hills, it’s an issue with DNS and may be either DNSSEC related (based on Vext’s experimenting) or that nslookup uses non-initially randomized transaction IDs for DNS (per Luke Baggett’s Black Hills post). Either way, it solved the problem.
That wraps up chapter 1. Lots of good info. There was a lot of stuff I’m familiar with, but setting up a Lightsail instance was definitely outside of my comfort zone. It wasn’t difficult once I made myself just sit down and do it, but there’s something a little more serious about setting up a VPS than a VM. I also spent some time playing with Armitage during an ICS training, and if Cobalt Strike is a better version of that, I completely see its worth.
I definitely need to spend some time with Empire and dnscat2. There wasn’t much hands-on stuff with the other tools, just getting them installed. There were a lot of installs that duplicated what’s already there with PTF. Hopefully the duplicate installs won’t break anything, but I know that’s a possibility. But the nice thing about a VPS is if it gets completely forked, I can either backup to a previous snapshot or kill it and make a new one. That’s not remotely the attitude I would take with a production server, but it’s nice for labs.
The amount of info in the book is very dense, and it’s definitely not a cookbook with exact steps and syntax written out. I feel like this is good and bad. It’s good because I’m having to look up more information about the tools, what they do, and how to use them. I’m also figuring out where I want to put things to stay organized since I’m installing some of the tools on my other VMs. There were several places where the earlier editions were referenced with the indication that the material wouldn’t be repeated in the third edition. I understand that, but it would have been helpful to have all of the material together.
I’m really glad I’m doing this for the book club in the BrakeSec Podcast Slack. Being able to bounce ideas off of the rest of the group has been invaluable. I would get through it on my own, but the accountability and having people to work through issues with is going to make it a lot easier. I hope to start getting my notes up closer to the book club discussion, but we’ll see how that goes.