Thoughts on PhineasFisher from an Enterprise Security Architect

If you didn’t catch PhineasFisher’s “Hack Back. A DIY Guide” I suggest you do. Here’s the link: http://pastebin.com/raw/0SNSvyjJ . It’s been covered in a number of places but I’m still finding a few people that haven’t read it. Here’s my pitch on why you should read it: it’s a shorter read than the Verizon or Mandiant reports. It’s a simple, detailed, play-by-play guide on how PhineasFisher compromised the Hacking Team’s operation. No muss; no fuss. Just well-written details from start to finish.

Here are just a few points I took away. Note: this is not a summary or synopsis. These are just some points that I think are interesting or informative.

The use of Metasploit and Meterpreter. I’ve been in several sessions with vendors where invariably the use of Metasploit will come up. An example: “I used Metasploit in this test. Your ID/PS should have seen that traffic to the host, shouldn’t it? Why didn’t it?” The answer is almost always some variation of, “Well, Metasploit is really for use in a lab and not in the real world.” This is, and always has been, absurd in my opinion. This write-up shows how PhineasFisher uses Metasploit and Meterpreter in this compromise. It’s a real-world usage and not a science experiment.

Storage and Backups. In section 9, PhineasFisher talks about how the backups are used to further the goals of the operation. This reminded me of a few projects I was on where securing storage –and in particular, backups – was the task. To be honest, I simply didn’t do an adequate job conveying the risk, the means and methods of compromising storage and backups, and ways to secure it. I’ll do better next time using these notes as education.

Section 5.3 really drives home the point of limiting your exposure to the Internet. I know this sounds trite but to this day, I’ve had clients unnecessarily expose devices to the Internet. Further, they expose so-called “appliances” thinking they’re hardened or some way, they’re magically secure. Even if we’re talking about a VPN concentrator, my thinking has always been to limit exposure. As an example, try not to expose the concentrator itself but instead put it in a “services” zone in your DMZ and only allow the necessary port and protocol through into that zone. And naturally, any monitoring and blocking you can do in that zone is a big bonus.

Outbound monitoring. I know a lot of people that drive this point home. This compromise is just another example of the necessity of monitoring all your traffic in and out.

Patching. Section 13.1 details lateral movement inside the network. It yet again drives home the importance of blocking and tackling in the form of patching. (For those of you from outside the US and not familiar with American Football, blocking and tackling is a euphemism for doing the basics). MS14-068 was used to take advantage of a bug in Kerberos to generate Admin tickets. Not to be obvious but patching that system would have made things just a little harder and as Blue Teamers, that’s the goal.

Go read it for yourself.

Note: Let’s not confuse my analysis of this operation and the key take-aways with any form of sympathy. I’ve written about this before.