Return to Sender: Bypassing Email Spam & Malware Filters

our next speaker this morning um is uh sebastian saller his talk is return to sender bypassing email spam and malware filters so please round of applause for sebastian thanks well uh first off i just want to thank everyone here for coming to the talk and i hope you'll be able to take something away from it now as the title mentions today we're going to be talking about email security and more specifically we're going to talk about a few techniques i've come across which can help you as red tamers to either reduce the operational effectiveness of email spam and malware filters or just bypass them entirely so before we get into it i'll just go over a brief agenda of what we'll cover

during the talk and of course i'll start off by introducing myself and who i am we'll then get into a background of phishing and i'll look to briefly provide an overview of what fishing is and how fishing has evolved to become what it is today we'll then get into what we're all actually here for and i'll look to answer the question of how can you as a red teamer gain assurance that your phishing email is ending up in your target's mailbox and to answer that i'll go through three distinct attacks namely the bounce attack the direct mail attack and the direct mail bounce attack we'll then briefly cover what you as a defender can do to mitigate against

these attacks and then we'll wrap up with some concluding thoughts so who am i as kylie mentioned my name is sebastian sala and i'm currently a cloud security engineer at mcafee before that i mainly worked in the msp space working towards federal government customers and security operations and assurance teams in my spare time i've been working on a phishing simulation service called can i fish and as well creating this service that i came across and automated many of the techniques that we'll be discussing today aside from that i've been in infosecond it for about eight years where i've worked in a variety of roles i've worked as a software dev an analyst an advisor consultant and now

as an engineer but that's enough about me so what is fishing phishing is a type of social engineering attack where a threat actor is attempting to masquerade as a legitimate entity or individual and commonly there's a few different goals in mind when performing phishing attacks either you're trying to steal sensitive information in the form of user credentials or credit card numbers either you're trying to gain access to a host system or you're trying to steal money directly from your target and this commonly comes in the form of blackmail or some form of trust scam and there's a few different methods that can be used to perform these attacks right fishing is a bit of a blanket term

so you can do email phishing website phishing sms phishing voice fishing you can also just send more general purpose phishing messages but for the purpose of this talk we'll focus on email phishing and i think this quote from mr robot does a great job of showcasing why phishing is so successful right we live in a world where just about everyone has some form of online presence whether it's a facebook page a twitter handle a linkedin account or a github page it doesn't even necessarily need to be something that you're actively publishing it could be a threat actor has the knowledge of your rough geographic location and maybe they use that to craft a spearfishing email that's imitating your

local city council saying there's going to be road works on this week and you know click here to find out more so it doesn't necessarily need to be something that you're actively broadcasting and what we'll do is we'll just take a bit of a step back and we'll go into the evolution of phishing to try and figure out how we got to where we are today where fishing is a threat that individuals and organizations face on a near daily basis and to do that we're going to go all the way back to 1996. back when aol was one of the leading internet service providers and for many people using services like aol and instant messaging services like

aim were the first time that we had used any form of an internet connected communication service and i didn't know it at the time but there was a whole underground hacking community associated to hacking aol users and ao hell was the first of what would become thousands of tools designed to help hackers hack aol users and most notably this tool had a phishing toolkit embedded within it which allowed its users to send random phishing uh phishing messages to random users to steal things like user credentials and credit card information and also notably this is the first recorded mention of phishing as we know it in this toolkit it's built with a ph by time we get to 2003 threat actors had

pivoted from sending phishing messages on aol to sending phishing emails and with that the result we also saw the introduction of phishing websites threat actors were scraping legitimate websites like ebay and paypal purchasing lookalike domains to look as real as possible and they're also leveraging more technical techniques like domain spoofing for emails and the use of email worms so not only would you be compromised as part of a fish but you would be leveraged to onward to compromise all of your contacts by the time we get to 2005 phishing is recognized as a fully organized part of the black market with losses in the us alone totaling to about three billion dollars by the time we get to 2009 bitcoins

released and this would fundamentally change the attack landscape in favor of attackers now they had a mechanism to accept funds without risking exposure of their identity it acted as a global currency so they didn't have to worry about local currency exchanges and also it provided a means to perform a non-reversible transaction so they didn't have to worry about banks closing their accounts or reversing that transaction by the time we get to 2013 we see the first ransomware campaign leveraging bitcoin as a payment method and in doing so it also became one of the most profitable ransomware strains of its time earning it to create as about 3 million dollars and this is important to note because

ransomware crews commonly use phishing as their primary point of infection and a recent example was just nine news last week they were ransomware and i don't think they've announced how they got ransomware but i'd be willing to bet it was probably a phishing email by the time we get to 2017 we again see the sophistication of phishing emails evolving threat actors have begun to abuse the very nature of how browsers like chrome represented websites that were https encrypted with a ca signed certificate browsers like chrome gave them a big fat green tick which to many users indicated to them that the website was safe trusted and secure but in reality it was just secure from the standpoint of

client to server communication it wasn't trusted and it wasn't safe by time we get to 2018 we begin to see the rising prominence of stego malware so malware is embedded within images to bypass things like email malware filters as well as host-based detection systems by time we get to 2019 we see vendor email compromise rising in popularity we saw this at the time with the cloud hopper campaign targeting the defense industry so threat actors would target the defense supply chain vendors because they didn't necessarily have the same security posture as defense itself did and then they would leverage that supply chain to onwards fish defense personnel and that brings me to the current state of fish where there are

hundreds if not thousands of open source and privately sold projects which automate the creation and management of phishing infrastructure phishing emails and websites look highly convincing utilizing a variety of technical and non-technical techniques to trick users and threat actors are abusing legitimate mail and authentication infrastructure for the delivery of high reputation mail right a target is far more likely to click accept on a malicious oauth app than they are to enter their credentials into a phishing website and on the surface it might seem like fishing is getting easier than ever but it's also getting harder because there are dozens of email security vendors who make it their number one priority to spot and block any malicious

fishing campaigns they come across and that's why we're here today i've come across a few techniques which can help you as red teamers to ensure that your phishing email is ending up in your target's mailbox and the first attack that we'll discuss as part of that is what i've dubbed the bounce attack and what we're looking at here on the right hand side of the screen is a microsoft exchange non-delivery report and exchange generates these non-delivery reports whenever an email fails to end up in a target's mailbox and in this case we're purposefully generating a non-delivery report by emailing a user that doesn't exist and in doing so exchange searches its directory says hey i can't find that user i'm going to send

a non-delivery report back to the sender so they know what happened and what we're actually using here is the fact that the default non-delivery report within microsoft exchange contains an untempered copy of the inbound message headers in the diagnostic information section and to understand why we can abuse those headers we have to remember that modern it solutions are developed with interoperability as a core functional requirement and security model gateway solutions operate no different they commonly use email headers as the vehicle to transport sensitive information along the mail relay right and they're commonly used in conjunction with other technologies so you might have a secure email gateway that's talking to a dlp solution that's talking to a

malware sandboxing solution which then finally hits exchange so by the time we get to exchange there's a plethora of information in those headers and that's exactly what we're going to abuse so if you can see on screen i've got a sample email from a target organization and we're going to dig into that non-delivery report to see what we can find and in this case we can see that the target organization is using soft pure message as their secure mail gateway we can see the spam and malware engine versions of software's pure message in use we can even see the spam filter rules that our email is getting analyzed against and ultimately we can even see the spam

probability assigned to our email now from an attacker's perspective this is hugely beneficial because what we can do with this is we can progressively craft the perfect fish a fish that we know will end up in our target's mailbox and the way that we would do that is by first of all sending an innocuous email no malicious content just to check that a bounce attack is possible and then we would progressively start adding more and more malicious content abusing bounce responses and avoiding certain keywords or url shorteners that we know are ticking off certain spam filter rules and once we have that perfect fish crafted we then deliver it to our target recipient knowing that we

are below a certain spam probability threshold and we have that confidence that will end up in their mailbox now look i've called out sofas pure message here but it's by no means isolated to just them this is an industry-wide issue where securimal gateway providers are just broadcasting too much information by default as part of their inbound message headers now in terms of exposure i did some quick lookups and i found that about 25 of the asx 200 are currently vulnerable to a bounce attack so there's definitely a lot of room for improvement within australian organizations that's in comparison to only 4.2 percent of the alexa top 1000 now look we've covered the bounce attack which is all about reducing the

operational effectiveness of email spam and malware filters but what about bypassing them entirely and that's where i want to talk about the direct mail attack and this attack focuses on abusing the implicit trust relationships we have when dealing with cloud native infrastructure and for the purpose of this talk i'll be focusing on exchange online when used in conjunction with third-party securimal gateway services and for this uh scenario i've got a target organization called contoso corp and contoso corp have a domain of contoso.com now they decide to go ahead and set up an office 365 tenant because of its collaboration as well as email delivery services so they go ahead create that tenant and the first thing they do is register

contoso.com with that tenant now behind the scenes whenever a new domain is registered with office 365 microsoft goes ahead and creates what's called an exchange online smart host and this smart host always follows the same structure it comes in the form of a dns record which grabs the domain name replaces any dots with hyphens so contoso hyphen com and then it tacks on mail.protection.outlook so from an attacker's perspective we always know when a domain has been registered with an office 365 tenant just by simply checking for the existence of this dns record and in this scenario contoso corp decide that they're using exchange online but the native mail filtering capabilities within it just aren't good enough

doesn't have malware sandboxing the spam rules are clunky or whatever issues that they came across they decide that they don't want to use exchange online protection so they go ahead and acquire a third-party securimal gateway solution and the way that this functions in the cloud world is contoso corp just simply updates their mx record so the intended user workflow is supposed to look something like this an external user contacts the securimal gateway via mxrecord the securimal gateway then forwards the email to exchange online which then forwards it to the target user now i'm sure many of you here can probably already see the issue with this we don't have to use a domain's mx record we can hard code the destination

mail server that we want our mail to go to so with the knowledge that an exchange online smart host has been set up we can just contact that exchange online smart host directly and essentially bypass that security more gateway entirely now there are a couple of issues with this right what if the target organization has set up prohibitive mail routing rules which prevent us from contacting exchange online directly or what if exchange online protection is still enabled right how do we get past these two hurdles and that's where i want to talk about the direct mail bounce attack and this attack is very similar to what we talked about earlier with the bounce attack except instead of just sending an email

to a user that doesn't exist to get a bounce response we're instead hard coding the destination mail server and then doing that bounce attack so essentially we're contacting exchange online directly and the reason why we want to do that is because we want to check to see if we can get this non-delivery report and the reason why we want that is because if we get a non-delivery report saying that that address couldn't be found then it provides us positive confirmation that a direct mail attack is possible and that's because if there's some other issue that comes up right we receive a response saying a prohibitive mail connector is configured which is blocking us from contacting

exchange online or there's some mail loop issue or one of a dozen other different issues that will come up if we receive any of those responses we know a direct mail attack isn't possible but if we receive that first response then we know it is and also importantly when we receive that non-delivery report we also get all that information that we talked about earlier we get those inbound message headers we can see how exchange online protection is classifying our email whether or not it would actually end up in a target's mailbox or if it go into their spam folder so if we run through a quick little attack scenario of how a direct mail bounce attack might look

an attacker would first of all check to see that a direct mail attack is possible they'd email a user that doesn't exist at a target domain they'd get that non-delivery report back and then they'd have that positive confirmation that a direct mail attack is possible they would then progressively start crafting that perfect fish checking exchange online protection checking to see if their emails getting classified as spam and once they're confident that their email won't get classed to spam by exchange online protection they then deliver that fish to their target recipient and in doing so they've completely bypassed the third-party securimal gateway solution they've reduced the operational effectiveness of exchange online protection to an extent that their email will end up in their

target's mailbox now in terms of exposure again i found there's a lot of room for improvement in australia so of the asx 200 143 organizations use exchange online 94 of that 143 are using a third party secretary gateway solution and 35 of that 94 are currently vulnerable to a direct mail bounce attack that's 37 percent of implementations where a third-party securimal gateway solution is in use so yeah it's essentially security by obscurity for those organizations and overall that leaves us with 17.5 percent of the asx 200 being vulnerable now look i've covered what you as an attacker can do to exploit these vulnerabilities but what about protecting against them so from a bounce attack mitigation all

you need to do in this space is overwrite the default non-delivery response that microsoft exchange provides for exchange online this can come in the form of a one-liner powershell command where you're essentially just overwriting the default non-delivery report putting in a one or two line custom message and when you do that that entire section the diagnostic information section that has those inbound message headers goes away right so you can just put something simple there one liner saying this address couldn't be found please try again or please try a different user for a direct mail attack mitigation this can come in the form of an inbound mail flow rule within exchange online and essentially what you're saying here

is i only want to accept emails directly into exchange online if they come from these particular ip addresses which would be your third party secure email gateway solution as well as ip addresses that you own now in terms of implementing these mitigations i would really put them in the easy category for both complexity and duration so it's something i highly recommend taking a look at if you think your organization's vulnerable now look wrapping things up these attacks can be performed by anyone on the public web right they don't need to have a sophisticated knowledge of your target environment all they need is a list of domains that they can manually or programmatically cycle through now in terms of checking to see if

you're vulnerable i've put together a tool that's accessible at the link on screen where you can just put your domain name in click scan and you'll get a report back in about 10 to 60 seconds of whether or not you're vulnerable to these attacks otherwise that's all thanks everyone [Applause] awesome thank you we have a few questions on the slack if you're ready to take them um do these attacks only apply to exchange no you can equally perform them on gmail yahoo or any cloud hosted mail exchange that's for a direct mail attack for a bounce attack that is unique to exchange i haven't found any other mail provider that provides a copy of inbound message headers in

their bounce responses um okay and nathan asked can i do direct mail attacks if the target is using an on-premise secure email gateway no so a direct mail attack abuses the the trust relationship we have with cloud native infrastructure essentially by default with cloud infrastructure if you have two points of entry we can contact either of those points of entry so we can contact the secure email gateway solution or exchange online but when you have on-premise infrastructure there's only that single point of entry of the destination mail server you can still do a bounce attack just not a direct mail attack yeah awesome another question can exchange not be configured to first forward incoming email to the third party gateway

rather than needing the given flow it can it can it certainly can um yeah and in some cases that is what organizations do so if that happens then yeah direct mail attack won't be possible but you'll be able to see evidence of that in the bounce response you'll be able to investigate the inbound message headers and you'll be able to see that microsoft exchange forwarded the email to the third party securimal gateway solution for analysis and then forward it back over but i haven't found many organizations have been doing that so it's sort of by exception yeah awesome and that's all the questions but i think you'll be around if people have more questions yeah i'll just be in the foyer area yeah

awesome and can everyone give a round of applause to sebastian that was a great talk thank you thanks