Shall we say… Good bye, phishing queue?

Imagine you stop processing your phishing reports today.

Just stop.

What could be the worst thing that could happen? Hmm ?

Of course, some people will still get phished, some will become Business Email Compromise (BEC) victims, maybe even launch macromalware, or witness some other badness, scam, but…

This is a very attractive proposal tho! Isn’t it?

10-15 years ago we had a lot of alerts from removable devices, drive-by infections, IDS, IPS, proxy alerts – today they are no longer that important. Should ‘phishing report’ join this group, and retire?

A lot of comms today happen via Instant Messengers (Slack, Teams), Bots, social media, often via always-online, often mobile platforms, and less and less via email. And many users and their systems are already very well protected by mail gateway security, endpoint policies, plus AV, EDRs, etc. And we have MFA in place as well. So what that someone nicks your credentials if they still need your MFA blessing to log in?

And what about submissions quality? Isn’t a person reporting a phish an employee that is actually very security aware? Since they are, there is really not that much to do there… Links are shortlived, often are non-blockable really (hosted on shared platforms), and the user _is_ aware it was bad. And some of them are so aware that, while it perhaps makes us feel really good about our Security Awareness programs, many of them become very trigger-happy and start submitting literally anything that looks ‘off’ in their eyes as… a phishing report, for example:

  • Company invites you to a webcast? Report.
  • Vendor sending you a newsletter? Report.
  • Real Amazon, UPS, DHL, Fedex tracking emails come in? Report.
  • Zoom recording email comes in? Report.
  • Request to reset your password comes in? Report.
  • Your peer shared a cloud-based link to a shared workspace with you? Report.

And so on, and so long. There is no end to it.

Many of these emails are legitimate, many of these nagging emails can be genuinely unsubscribed from. But hey… we are all so AWARE… so these reports end up in our ticket queue, instead.

It’s a dumpster fire.

And perhaps it’s time to start looking at it from a different angle.

There are 3 angles I think that are interesting:

  • auto-closures
  • processing in bulk
  • focus on emails outside of phishing reports

The first two are a natural progression of a tired SOC/triage handler. Thinking of how one could go about closing tickets faster various ideas may come to mind — note these listed below are not ready-to-use recipes – your risk appetite depends on the org you work for, and there are obvious and non-obvious caveats in the below examples:

  • If the emails are internal, you may just want to auto-close (with a risk acceptance of malicious forward, compromised email and internal phish).
  • If the emails come from verified sources (proven not to be spoofed), we can autoclose it. There are tones of low hanging fruits here: anything that uses ‘noreply’, ‘no-reply’, ‘support’, and many variants of ‘unmanaged’ non-spoofed mailboxes like these from ‘big’ players and legit companies (do the stats for your org!) are these that can be auto-closed.
  • If it’s a repetition, we can close. This is non-trivial, given differences in headers, recipients, etc., but feasible.
  • If it is a known pattern from a known address f.ex. ticketing systems sending gazillion of ticket notifications we can add rule to auto close all of these that are reported as phish.
  • Emails w/o attachments? And all extracted links point to well known domains that are known to be non-malicious (need a database of these)? Probably can auto-close too.

And so on and so forth.

We may shave quite a bit with such approach. But there is a need for a risk acceptance for all of these auto-closures, of course.

What about bulk processing?

Imagine a world where you don’t look at phishing reports as individual tickets, but review them in bulk?

A selective, carefully crafted excerpt of data dump of say 20-50 phishing reports one by one, perhaps in a table, could save us a lot of time. Instead of doing gazillion clicks to manually open/close each and every one, individually, as tickets, we cluster them together and close them as a single unit. 5-10 clicks, instead of say 200-500. One person spending 30 minutes on it, instead of 5 people spending 15-30 minutes per each ticket. There are some substantial personhours to win at stake, and it’s worth looking at!

With bulk processing, you can very quickly pick up and rule out emails that are your regular spam, cherry-pick BECs, find emails with attachments (they may need additional time for analysis), etc. And if you look at the above list, you could immediately envision doing separate bulk processing for emails with, and without attachments to speed things up.

Most of email headers are useless for analysis, yet all of them usually make it to the tickets. Why not trimming them down? Showing only these that are relevant? Well… you may ask ‘which ones are those’? Do a brainstorm session with your analysts, look at how they analyze the emails today, and cherry-pick the information you would like to see first for individual tickets, and then inside a bulk report.

In my mind, analyzing emails reported as phish contributes to the highest waste of cyber cycles ever, and we need to start thinking on how to cut this down. You can literally save hundreds of thousands of dollars by adapting a more modern, even borderline risky approach to handling these…

Can you sell it to your CISO, compliance, client’s auditors…? Today, probably no. But if we as an industry start making changes then these approvals will inevitably become a new Business As Usual (BAU).

That leaves me with the last part.

How many of us look at emails that are NOT reported as phish? This is where the real, undetected BAD happens. This is a gold mine of opportunities to detect that badness, but somehow it’s not a priority for many. There are obvious privacy and information sensitivity issues to tackle (access to body of emails should be really heavily restricted), but even with some basic metadata we should be able to find some interesting stuff. We could start by ruling out legitimate emails and campaigns (f.ex. internal emails, emails from the unmanaged/non-responsive emails, etc. etc.) to arrive at a significantly reduced data set which can then eyeballed same way as bulk processing. This in fact, is, a nice compensating control to your current ‘analyze email phishing reports only’ process!

So, imho bulk processing is the future of email analysis. We apply same threat hunting principles as we do to EDR. We hunt for bad, we hunt for good and narrow down the scope saving lots of time, combating alert fatigue, combating FP fatigue, improving morale in the end, and still keeping your organization safe!

There is almost no value in a single phish report, but there is certainly a value in us optimizing our processes. If your queue is made of 30%+ phishing, this post is for you, and it’s time for you to act.