Email Top Threat Vector

I’ve been focusing on rapidly getting better at being an email security engineer.
Part of this has been paying close attention to the slew of email security configs out there.
The other part has been keeping up with the latest threat trends.
I’ve been noticing more and more that outside of vulnerable servers and Microsoft endpoints, email messages appear to be the leading threat.

2021 Kimsuky Campaign

Kimsuky is a North Korean APT.
In November, Proofpoint released info on an investigation into a campaign that Kimsuky was actively running.
The campaign involved the APT using the Google Blogger platform to target HVTs (High Value Targets).
The attack chain was:

• Delivery of malicious microsoft documents (maldocs) via email
• Maldoc macros reach out to credential harvesting page
• Cred harvesting page was later turned into a malicious binary dropper
  Kimsuky apparently ramped up the campaign as they were reaching great success at their phase 1 cred harvesting.

Sneaky Emerging Javascript Loader

This month HP released info on an emerging threat in the javascript domain.
There’s a newly discovered way to leverage javascript to do nasty things.
It’s newly discovered by blue teams, not newly developed by bad actors.
The malicious javascript functions as a stealthy loader for what is now dubbed “RATDispenser”.
RATDispenser is just a dropper for an actual RAT, stage 1 in a two stage process.
There are multiple variants each under separate active development trees.
The delivery method for RATDispenser is a phishing email containing a “txt file” which is realyl obfuscated javascript.
The javascript then writes a vbscript, which then downloads the final stage payload.

Iranian Microsoft Windows MSHTML Exploit via Pshell

SafeBreach released info on an Iranian-on-Iranian attack leveraging powershell to exploit CVE-2021-40444.
The powershell script exfiltrates endpoint data and apparently has a lot of functionality built into it.
Guess how it’s delivered to endpoints?
Starts with a phishing email, delivery via malicious office documents (maldocs).

Tardigrade Malware

Tardigrades are wonderful little creatures.
The cool new metamorphic malware known as Tardigrade has been getting delivered via…
Phishing emails.

I have noticed the following trends out in the field…
Successful threats come in from spoof domains, visual attack domains (doma!n.com), freemail (gmail.com), or compromised partners.
Spoofs can be filtered out with some sort of forged email check, which checks the friendly-from against a list of c-level execs.
Visual attack domains can be filtered out usually either by reputation checks, or a check against a custom list made with open source typosquat generators.
Freemail can’t really be stopped without first receiving the attack, then blocking that sender, unless they’re using the freemail account to spoof.
Compromised partners is a difficult one, outside of first receiving the attack then building out custom rules, I haven’t yet found an easy solution to that problem.

Successful threats leverage a safe document which internally hyperlinks (think sharepoint) to a malicious URL.
This is a difficult one, because without a CDR solution which utilizes deep scanning, it is hard or impossible to strip friendly URLs from a document.
There are safe-print or URL defang or rewrite capabilities in most solutions, but that still doesn’t neutralize the link.
The solution of “block all attachments” doesn’t work unless you don’t actually use email.
The solution of “block all attachments” paired with “from anyone that is not in this list” works UNLESS your partner got compromised, then sprayed out phishing emails to your users.
I’ve seen some org’s compile a list of the partners who typically get compromised, and add them to a separate high-security list or rules.
Most of the email security solutions have a safe Web Proxy to take users to once they click an in-body URL, but that is circumvented with in-document URLs.
As long as an in-document URL is clean (again, think sharepoint redirect links), then what can you do without a CDR, sans well-built implicit deny policies?

It seems that there is no pre-baked solution when it comes to infosec.
To mitigate a decent amount of email security threats, you almost NEED a spaghetti monster of policies that have been carefully and methodically built.

Unfortunately, that is as rare as a dev who has finished every project they’ve ever started.
It’s definitely not hopeless, though.
I see a lot of configs that are obviously well thought out and are extremely effective, pretty much cutting out all the nonsense and allowing External Threat Feeds to catch emerging threats.
I used to think that the above is how all email appliances came pre-configured but that is not the case.
It takes dedication and configuration to tailor an off-the-shelf solution to your particular environment and threats.