Last weekend, I posted to the popular social news aggregation site Reddit about some common problems I’ve run into during penetration testing engagements.  This post became very popular, so I thought it made sense to post it to our blog, as well.

I provide pentesting services for small and mid-sized businesses. For the past year I have almost exclusively gained Domain Admin privileges in my clients’ networks due to weaknesses in their backup architecture. Most of these companies are using some sort of Linux-based NAS to store backups, and connect to it using SMB. Most of the devices I’ve encountered have been vulnerable to SambaCry, which makes it trivial to gain a shell on a Linux device. While a device I encountered yesterday was fully patched, the vendor apparently forgot about this device when fixing a certain authentication bypass on similar models. This allowed me to gain access and grant myself SMB access to the file shares.

Once I have access to system image backups, it is trivial to extract local NTLM hashes from the SAM file stored within the image and use that in a Pass-the-Hash attack against any machine on the network using that local account. If accounts share the same password but have different usernames (like in the case of my client yesterday), the same hash will still work without issue, since NTLM hashes are not salted. In the event that I get the backup of a Domain Controller, I can extract ALL user hashes for the domain from the NTDS.dit file, allowing me to do PtH across the entire network.

There are some best practices things to do to help prevent this type of lateral movement, such as using LAPS to manage local admin passwords rather than using the same password for every machine. However, the thing that seems to be overlooked the most is securing the system image backup files. If the backups were encrypted, it would be much more difficult to access the data, even if I got into the NAS. In the case of my client yesterday, some Backup Exec backups were encrypted, but not others. I was going to try to get into one of the unencrypted backups, but then found a random Windows Server Backup image file and went with that instead (since that stores backups in VHD files, which are simple to mount and browse on my Kali box).

So, the moral of the story is: encrypt ALL of your backups, even the ones on-site and supposedly secure. Even if you think “well, if they’re in my backup system I’m screwed already”, you might be able to limit the additional access an attacker can gain.

If anyone has any questions about this or other SMB (the sector, not the protocol) related pentest topics, ask away!

EDIT: Glad this post gained traction! I wanted to also share another attack that I used on this last engagement. Long story short: it’s best practice to block all unnecessary outbound traffic from your corporate firewall. However, if you haven’t don’t that yet and it’s too risky to just pull the trigger on that without determining what needs to be allowed out, if nothing else, block all outbound SMB traffic (ports 135,137-139,445 TCP/UDP) on the corporate firewall, and also push a GPO that blocks that same traffic going to WAN IP addresses on each workstation’s local firewall, too.

I found a way (that I haven’t seen documented in any blog posts yet) to exfiltrate NTLMv2 hashes from remote users from simply getting them to open a seemingly benign HTML file in Outlook. I’m not going to post the specifics, but the implementation was very simple once I figured out what existing controls browsers have in place against it and I got it to work in every browser tested (IE, Chrome, Edge, and Firefox). There is nothing inherently malicious about the file in question, so it will not be picked up by A/V and unless you block all HTML attachments, you can not block it from coming through. The solution is simple: block outbound SMB to WAN IP addresses (basically everything that is NOT RFC1918).