OPSEC failures when threat hunting

Over the last few years I’ve carried out a lot of phishing, and have some interesting observations on how organisations respond. However, the purpose of this blog is to highlight a worrying (and amusing) trend in response actions taken by the blue team and researchers when threat hunting a phishing attack.

I know kung-fu

A typical engagement will, after a period of OSINT, involve sending in various phishing emails, often without the blue team being aware of the engagement. These are not typically tied to a red team and so the usual stealth is less of a priority, however, security controls are not typically weakened, and so normal threat response processes are left to run their course.

In a recent test I sent in a really simple spoofed Microsoft forms email, the goal was to just test a base level of security awareness without much complexity. Nothing particularly advanced about it, just a simple email showing that a staff survey needed to be completed. Below is an example, but not the one I used on this test.

The link was trivially obscured behind the ‘start now’ button and went to an Azure CDN link that fronted a very basic spoofed Microsoft 365 logon journey. So far, so simple.

Also in the email was a UNC path to an SMB server running Impacket, this was designed to silently attempt to collect NetNTLM hashes as an alternative to user credentials simply by opening the email. Although this is commonly blocked within the organisation, staff working from home typically use a split tunnel VPN to save bandwidth, which often allows this traffic outbound.

A disturbance in the force

So I sent in the phish …and not a lot happened. I recorded five people open the email, but no NetNTLM hashes were seen and no submission of credentials.

It turns out the first person to open it immediately reported it to the IT Service Desk and notified the wider company. My security awareness trainer brain was happy, my phishing brain was sad.

However, that’s not where the story ends…

What then happened was that three other people attached the email to a new email and forwarded it to the IT department for investigation, which is where it started to get interesting. It is thought that these IT staff were working from home and had a split tunnel VPN enabled. They then opened the email in a native Outlook app and, even though they were not the intended target, I collected their NetNTLM hashes along with their workstation ID, domain name and username. D’oh!

These hashes need cracking, which was not within scope of the assessment, but it clearly shows a process failure in response and a lack of understanding of the threat within the blue team.

Who watches the watchers?

However, this journey took an even more amusing turn with what happened next.

The blue team did have the forethought to not open the link in their own browser and used the Browserling service to view the link. Kinda decent OPSEC.

They then decided to pass the URL for one of the users through Virus Total, which did not report any providers suggesting it was malicious, accurate given it was unique to the client.

Virus Total shares all content uploaded, including URLs with security researchers or anyone who wants to download it. Its not unheard of for a non-diligent security researcher to enter credentials to get access to the malware.

Which begs the questions, how are you responding when you receive suspicious emails. What OPSEC controls are you taking when threat hunting?

One security researcher even submitted what appeared to be VALID Microsoft 365 credentials into the phishing site. I didn’t test these for obvious reasons.

Which begs the questions, how are you responding when you receive suspicious emails. What OPSEC controls are you taking when threat hunting?

You’re so different. You’re so perfect.

It’s really important that your blue team response processes consider the impacts of their investigation. It’s easy to simply open the mail and look at the link, but how are you doing that in an OPSEC safe way? If you don’t have experience in analysing suspicious materials, leave it to the experts.

The SMB attack I used even works when viewed in the preview pane of a native application such as Outlook, it doesn’t have the effect of leaking hashes when viewed in a web version.

It’s recommended that investigators use a sandbox to open suspected malicious emails, Windows 10 and 11 provide a simple sandbox, it needs enabling and doesn’t have desktop applications installed. Although that is useful in our case. Open Edge in the sandbox and use the web versions of your email client to open the email.

For IT departments using split tunnel VPNs consider setting firewall rules to ensure that port 445 does not leak out when not in the office.

You can then safely examine the link and without fear of browser exploits compromising your computer, even if they do, the minute you close the sandbox everything is erased.

Caution is needed

I would caution against uploading emails or files or even links to Virus Total, AnyRun or similar services without being sure it is not genuine, if these are genuine files you could accidentally leak sensitive information to anyone with an account for the service.

If you are a security researcher, I think it goes without saying, be very careful with data from Virus Total or others, the things you find on there are suspected malware after all. For the avoidance of doubt don’t enter real credentials on phishing sites or execute malware on live systems.