2019 was a big year for us at Pulse. We found a lot of bugs, compromised a lot of boxes and wrote a lot of reports. This post will provide an overview of three generic things that made our lives as attackers difficult last year. We’ll cover strong password policies, multi-factor authentication and a surprisingly effective phishing control. This post explains how these security controls made a few of our engagements harder for us.

As attackers, we spend a lot of time operating in the ether between systems, inside the minds of social engineering targets and figuring out bizarre ways to compromise systems. I want to give some insight on security controls that we came up against last year that made our lives suck. There’s always another vector and another way to exploit the target (In the immortal words of Dr. Raid - “Any box can be popped with the right resource”), but as far as controls go, these things were just the worst.

Note: When I say “the worst” or “this sucked” I mean that as someone whose job it is to compromise systems. If you’re on the defence side of IT, then anything that makes me want to cry is likely good for you.

Strong passwords - Phrases not Cases, yo

Internal penetration tests are usually fairly easy for us, usually. You turn up, you run ‘responder.py’, you go make a coffee. You come back to a bunch of captured password hashes, you crack those hashes and now you have Windows domain usernames and passwords (woo). Depending on how the internal AD is structured and what those users have access to, escalation is sometimes as easy as RDPing into the domain controller. Otherwise, we start compromising other boxes, capturing more credentials, dumping memory, etcetera etcetera.

If multicast name resolution is disabled then we move on, start doing more recon and by the time the coffee has kicked in the consultant has a few good leads for where to continue poking. Maybe we use IPv6 to hijack the DNS server, maybe we go old school and do some ARP poisoning.

One of our team worked on a notable internal pentest last year. On this job, the consultant captured a bunch of password hashes using responder. We spun up a GPU cracking instance in AWS and set it to start breaking those hashes. We got nothing. Zilch. Nada.

Turns out this specific client had followed the new-and-improved NIST guideline and set up a password policy that required 20 characters, no complexity requirements and no password expiry. They encouraged users to set up phrase-based passwords that were easier to remember, but extremely difficult to crack. Thankfully in Windows-land we can often relay hashes without cracking them, so we’ve updated our methodologies to focus on relaying right out of the gate, rather than just capturing and cracking hashes as a first step.

This job still ended up in a domain admin compromise, but it took the consultant a few days as opposed to a few hours. The consultant needed to rely on other techniques, such as hash relaying and trawling through open file shares for useful files. Strong passphrases turned what could have been a cakewalk into an engaging engagement. (hurr)

Quick tangent, including admin credentials in documentation is not a good idea. Also serving dynamic websites from open file shares is generally not a good idea either.

Multi-factor Authentication - Hello, yes this is Dave from IT can you plz….

Multi-factor authentication has been the bane of many a red-team engagement last year. So much, in fact, that part of our methodology is performing thorough reconnaissance to find things on the internet that don’t have MFA enabled. That old Citrix gateway that’s running in that rack that you’ll decommission eventually? That’s what I’m talking about. We live for that.

An external penetration test last year turned up an admin interface exposed to the internet. I chained that with a username enumeration vulnerability to build a list of valid usernames for the target. Next, it was brute forcing time. Live brute forcing is a bit of an art, you only get so many tries a day when you don’t know the lock out rules, so I had to be conservative. The password Summer2019 came to the rescue and brute force attack found a valid username and password pair, victory!

So I punch in my fresh new creds and am greeted with a prompt for a multifactor token.

:-(

Further exploitation now means finding contact details for that user, calling them up and pretending to be someone from IT that needs them to read off their multifactor token. The end result is a much higher chance of the target user getting wise and the attacker (me) getting busted.

Building on that, even if the scam works and we get a valid multifactor token, now we have a valid session and the aim of the game becomes figuring out a way to persist access to whatever system we just gained access to. We can’t just stroll back and login whenever we want using a username and password. If we mess up our persistence, time to call ol’ mate Bevan in accounting and try get another multifactor code. The margin for error becomes much tighter and the whole job ends up being more stressful (which is good, stressed attackers are sloppy attackers).

External link banners - You’re a winner! Click here to receive your malware

We’ve performed quite a few phishing exercises last year, either as stand-alone engagements or as part of a wider red-team engagement. One engagement stood out for me. We were asked to phish an organisation’s users, so we wrote some custom malware, registered a similar domain and put together a scam we thought would work well for this target. This was a combination of a credential harvesting and malware-download attack in one email.

The credential capture rate was around 85-90%, and we had about 50% of those execute our malware. In the end we called the client and terminated the campaign before even sending our entire volley of emails. The client was understandably confused, given they just went through and performed security awareness training! What happened?

Turns out performing security awareness training is not enough, especially when up against targeted emails. Robust security architecture and building internal security culture is the way forward, but this is a long term mission. Ideally the organisation would have tiered defences, secure architecture and response capabilities so that when someone is compromised, this does not mean that the entire network falls open. Additionally, you want to give your users as much help as possible when it comes to identifying phishing. This means more than just undergoing security awareness training, this means building additional helpers into mail systems that can warn the users when something suspicious is going on.

So security awareness training wasn’t enough to stop us, but this post is meant to be about things that made our lives suck. Not another post on Victory for Team Attacker! In the phishing realm, this ended up being external-email banners. When a user receives an email, if it didn’t come from your domain the email gets a little red banner that says something like EXTERNAL EMAIL: Be careful clicking links. So when we turn around and register something like YOURCOMPANYNAME.eu, the banner pops up even though the domains look similar.

The banner was strangely effective. We ran a scam with our usual rigour to make everything look legitimate, email signatures all good and so forth, and had noticeably less success.

Here’s a Microsoft answers link that explains how to set up an alert banner in Office 365, you end up with something like this (image courtesy of the Microsoft forum):

I feel it’s important to mention that we don’t have the data or metrics to claim that this is a 100% effective control, and this post should not be taken that way. This is simply something we noticed that made an engagement tougher for us. I didn’t expect a one-line banner in emails to hurt as much as it did, but here we are.

If you combine this technique along with showing your users what targeting phishing attacks look like for your specific organisation (send screenshots, don’t forward the original phishing email!) then you can include your users in your defences. As IT security professionals, it’s easy to get into the old habit of treating users like cattle and dictating how they should do their jobs. Instead, if you can involve your users in the ongoing security process then they can build an understanding of the practical attacks they’re facing on a day-to-day basis. It’s up to us to teach Maurice from marketing how to box.

Summary

2019 was fun, we all learned a lot and hopefully managed to help our clients become more secure in the process. If you’re on the defence side and you want to make attackers lives harder, then these three things might be useful. If you’re looking for more guidance on where to begin, CERT NZ’s Critical Controls list is what you want.

As with any security control, these things need testing after implementation. Did everyone use the new password policy? What about the accounts that never expire? Is MFA applied across-the-board for internet facing infrastructure? Are your users paying attention to the external-email banner? Test your controls and figure out exactly how effective and consistent they are.

Data and metrics over marketing and guesses.