BEC Unmasked: Real-World Attacks, Tactics & Lessons Learned - Andi Ahmeti

That's okay. Hello everyone. Thanks for coming to my not so boring talk, Daniel. Uh we're going to uncover today some TPS and some real world attacks related to business email compromise. And uh I know that business email compromise can be sometimes boring. Some people call it call it boring. I'm not don't want to mention names, but I'm going to try my best to be not so boring. I'm going to try my best to uh uncover a part where uh not all of us have heard of maybe some of you had but personally I didn't. So um agenda going to go quickly about introduction the best part which is going to introduce myself. We're going to talk about uh uh really quick

overview of business email compromise. Uh we're going to talk about inbox rules. Uh how they are being u leverage into the real world. Uh and instantly we're going to talk about some uh business email compromise scenarios which happened. Um what were the tactics that the attacker used? And um of course we need to talk about how to prevent them and uh detect them. And a quick summary uh my name is Zia Ameti. Uh I live from and come from Pristina. So from this uh city I've obtained my uh bachelor degree at University of Pristina and currently pursuing my master degree there. Um I started my uh journey uh in security as everyone as an offensive uh security

then jumped into uh permisso and where I work as a threat researcher for the past two years and I've had the pleasure of working with um some great people from Albania and Kosovo uh also from US. They're not bad. They're good. They're doing good. And yeah, so um at Permiso, we are a cloud uh security company focused on identity and we love to catch bad guys. And um also uh besides catching uh bad guys, I also inherited a a strong desire to develop open source tools and also present them at various conferences. uh one of them being uh cloud grabbler which is a a defense cloud defensive framework uh tool and also cloud console cryptographer uh a

tool which I co-authored and presented at blackhead Asia with my beloved ex manager Daniel Bohannan which he happens to be here thanks okay um agenda first we're going to talk about business email compromise just a quick highle overview uh as we know There has to be initial access and that can be gained various different methods of fishing. um uh where we can lure the victim into give us the credentials to hop into their account and that can be achieved through different methods of social engineering and yeah or you can just find them online if there's a data leak or you can buy those uh credentials after you have the initial access to to go into the victim's email account. Um

attackers typically don't jump straight into the attacking phase. They will start snooping around and read emails just know who is the uh to to get some key points. Who is the CFO, who is a CEO, who are the um security uh guys. So they just want to know more about uh your environment as you would if you if you had initial access to a server. So you first do some enumeration phase. Next, they will try to forward those emails to their own account so they have more time or they know that if they lose access to their to the uh compromised account, they still have those emails and also they will try to elevate uh

their their privileges. After the recon and preparation phase is done, we have the execution phase where now the attacker after um having more knowledge and uh getting to know more about our environment, they start start to impersonate the victims uh the victim which they compromised and that can uh be different in it varies. So if they compromised uh a financial officer officer, they start to uh impersonate that person and start sending out invoices and stuff. If they impersonate a a security intern, we know all what happens next and they always love to uh have special requests. So everything is urgent for them. Uh I think that's the best way into tricking human emotion. It's better than uh and

it's it happens to be more uh successful than tricking machines because till now they don't have feelings and last but not least they complete their mission can be data theft uh it varies based on their motivation if it's just financial gain or to just to mess with someone. Okay, the BC is done. Don't worry. Now we're going to the the good stuff. So we're going to talk about inbox rules and uh their role. Now who from the audience knows what inbox rule is? Don't read it but just if you have used it or you know its meaning. Yeah nice lot of you. So an inbox rule is a set of conditions which are applied to all incoming emails and when these

conditions are met uh specified actions are applied to those emails. Okay, the really really uh easy and straightforward. Now let's just um highlight some key keywords. So we have two condition and actions. So conditions are grouped into five categories in um in Outlook. So the first one is the people condition where you can basically filter down on from uh so this should be an SMTP address, an email address. You can also filter based on the emails that you're sending. So two or emails received for other. The third one I never understood what it does but okay it's there. Uh we have the my name is if you this condition just checks if your uh name is present in any of these

fields. A highly used one is the keywords condition. So you can basically say okay if this keyword exists in any of these fields. So if it exists on the message body on the sender address on the recipient address or on the message header. And another one is where you can filter down on the subject where you can filter if a keyword exists on the subject or on the subject or body. And the on the others which is quite nice one is um the first two are where uh the uh conditions where you can filter down on uh message size. So you can say basically if a message has uh is larger than 10 megabytes just delete it or

whatever action you do. And the bottom two ones are uh conditions where you apply them based on a daytime. Next is uh actions. So there are some other actions uh group of action but I just uh want to highlight three of those so you don't get sleepy. Uh the organized one where you can essentially move emails uh to another folder. You can copy them, delete them, pin to top. You can mark a message as read as junk. So all of these are again actions where um they go with inbox rules and you can change the route of the email. So you can forward them to another email, you can forward forward them as attachments and you can also

redirect them to another email. Okay, now enough talking. Let's start and actually create an inbox rule. So this is the Outlook web application view. You can also do this on the thick client on desktop. So we're calling a rule named delete immediately. And if you click on the condition tab, let's choose the from condition. So we're specifically deleting any email from this specific person. And uh yeah, we can see that the action is delete. So essentially, if this guy sends me an email that will straight uh go uh straight down to trash. So it will get deleted. Another useful way for to use inbox rules is deleting marketing emails. Let's say you created a an account and you

accidentally click on the on the button that you want to receive new offers or uh discounts from that specific uh uh page. So essentially here we are adding a condition which says if the subject or the body of the email contains any of these keywords just delete it. Okay. So these are some useful ways uh that you can uh use inbox rules. If you look closely on the second paragraph, it says that when inbox rules are set up correctly, they can significantly decrease the amount of time that you spend on inbox management every day. They will reduce the likelihood of you accidentally opening a malicious message and make it easier to notice new messages from important senders among

other things. So, I specifically uh stopped at those uh words because we're going to keep them on our on our um I don't know what this is. I forgot. Yeah, no worries. So, we have four words. And now um let's let's think from an attacker's mindset. Now, what if we get this uh words and uh we just want to we want to be attackers. Now, uh let's put the attackers cap. So, we're going to just do a foo them and let's let's do a revert them. Let's get the anonym of these words. So, instead of having um correctly, we're going to use misused, instead of decrease, we're going to use increase. And instead of easier, we're

going to use harder. Now, let's take these words and put them back on their places. So, now we have some a new definition about inbox inbox rules. When it says that when inbox rules are misused, they can significantly increase the amount of time you spend on inbox every day. they can increase the likelihood of you accidentally opening a malicious message and make it harder to notice new messages from imported sender. Now knowing this like having an attacker's mindset let's see what is an important email and let's try to recreate all this definition that we just uh said and uh the first one is deleting an important email. Now an important email can be different various. Now this is

not an important email to me and if you're a fellow University of Christina colleague this is also not important email it comes every second hour. So yeah you get the point but to us as a security persons important emails are when a new security info is added on your Microsoft account of or if your password is changed if u you get a security uh report about the suspicious activity on your account. So these are at least to me as a security person and to all of us important emails that we they are deemed to be uh uh necessary. So now let's delete this one. Let's h call the rule name inbox optimization. The reason why we call the um rule name

inbox optimization. There's no clear answer but we'll find that uh later on slides. And we're adding a condition where it says that if the subject or the body email includes any of these keywords. so that you can you can be generous on keywords. Uh just move it to the deleted items. Now moving to the deleted items and specifically adding the delete action essentially does the same thing but it just um looks different on logs. Now so yeah uh I forgot I added this. So essentially if we were to get an email from our from octa or from any IDP or from uh I don't know Microsoft it doesn't matter that your password is changed that

essentially let that inbox rule will get swiped out. I don't know if I did this how I should but yeah. So this will never reach our inbox rule but deleting emails or using inbox rule where uh uh where the deleted items is specifically mentioned can trigger some alarms. They are they can be and they are highly monitored. I hope they are. But now we instead of deleting them we are just hiding. Let's call a rule uh archive all emails. We're going to use the same uh conditions but now we are adding an action which will move these emails to a folder called old receipts. Let's say that we uh we are a financial officer or we did um compromise someone

who deals with uh receipts and if the defender are not doing the proper if they are not looking how you should probably on the uh condition but let's say you are just doing some sort of baselining based on rule name or actions you will totally miss this one because uh all the receipts it it shouldn't be a malicious folder at least is not deleting it. Now another u interesting found uh find is the lookalike folder. So uh we all know what the inbox folder is. So technically you cannot delete it. But can you create another folder which says that uh it has the name of inbox? Clearly not because that's already that already exists. But what what if we add

another space at the end? Yeah, this gets this is this is different. Uh so we just created a new inbox called inbox and a space at the end. What we found is that by using the Microsoft graph API on and combined with PowerShell exchange module is that we can add another flag which is the is hidden. Now how many of you have you actually known that you can create a hidden folder inside your inbox and or let's rephrase the question. How many many of you have uh tried to change the view of your inbox in Outlook? One. Two. Okay. Personally, I didn't. I didn't know that's an option. But if you specifically add this u uh flag, uh the

folder will get created, but you will not see it on your uh Outlook web application, neither on your thick client. So that's a nice way to or let's say UI way to obiscate and to hide this folder from the user. Now instantly after I found this I said like yeah I have an idea where I can use this hidden folder where create a new inbox rule which will essentially filter down on uh admin keyboard and it will move it to this folder and the folder we just created is called inbox. It has the space at the end plus it's hidden. And the reason why and if you check the Microsoft graph API so if you

query the get inbox rule you will see that it's essentially moving to move to inbox the the folder that this um email gets forwarded is to inbox which makes no sense at all because if you get a new email it will it will go to inbox but still you can you can trick you can trick defenders into doing that. So yeah, on the left on the your left side you can see the um Outlook web application and the view. So there's no inbox folder. There is but uh there's not the one we just created. And on the right side we have the runtime logs where if you are not really careful this would look like a an inbox folder but

essentially it contains the space at the end. So it's a it's a completely uh different folder. Uh another useful way is forwarding forwarding important emails. So yeah, you can use uh I didn't mention you can use more than one uh condition. You can use two conditions. So let's say we want just to forward everything that uh has to do with confidential or uh invoice whatever to a to our attacker's uh email address. Okay. So we know what inbox rules are. Let's see how they are being used in the wild. The first scenario is um we got a suspicious login from a from a VPN and that immediately triggered a risky sign on u alert. Also we got some access

anomaly based on uh IP address location and user agent and our beloved threat hunting team did jump straight in and started to investigate this case. So the activity was as follow. We got the mailbox login. So an intruder we think that uh that intruder successfully logs in into the account using probably compromised credentials. And uh right after that that uh the the attacker uh retrieves 170 emails. So it the mail items accessed event was called 170 times. So that that u does include does conclude the point of reconnaissance and preparation. So the attackers first are getting to know more about the environment they just compromised right away that they did um they did move an

email. So they moved the email from the junk folder to the inbox. So we we all know what uh what gets stored on on on a junk folder. And last but not least, they did uh create a new inbox rule. Now let's stop more about and uh about this inbox rule and just uh uh put this uh inbox rule on a suspicion scale. So first the intruder creates a new inbox rule to automatically delete any email which is received after the date of 17th February and that was the date of let's say the imaginary date of uh compromise. So any emails that are being uh sent to this uh compromised account will go straight down to the uh trash folder. Um

first we got the delete emails which let's put it to uh to the score two for this one. So uh it doesn't have to be uh suspicious. We have the stop processing rules which is another flag which essentially says that uh any emails any new inbox rules which uh are um let's say have to do something with the uh date they will not be prioritized. So the the inbox rule we just created uh is has the uh priority regarding the uh condition it just we just created. Next we use the received after date. So this is another condition but what stood out the most it was the rule name. So if you remember I told you

that you need to create some uh if you are an attacker uh create a normal rule name if you don't want to be um instantly to trigger alarms on on the defender side because this this is just I don't know it just like they they didn't have a decent of just creating a normally ruled name and maybe maybe they wouldn't have stood up uh as they did but yeah a key point or a major red flag is uh uh not gibberish but I don't know a rule name which doesn't make sense. It's just like typing on the keyboard. The next scenario is a funny one. So again we have the initial access it triggered alarms uh and uh we jump

straight down to it. So first uh the user instantly created two SharePoint folders. So it did create a share uh shareepoint folder under the app uh and created a folder called apps and another folder under the shared documents uh folder called attachments. They didn't upload a file there. It just created them instantly. They did create a new inbox rule and these attackers were ruthless. So they didn't really care to filter down. They just said like you know what everything that comes any email that comes from now on just just delete that. it doesn't have it's not necessary. So on a suspicion scale this was quite interesting. It did because um it did not use the condition but still

the rule name was quite suspicious because they just used four uh characters and those characters were like uh dot semicolon uh I don't know not something which makes sense. After that uh the user did create an email and uh as a draft message with a subject important update which is kind of suspicious because as I said they are always on a hurry. They always tend to exploit human nature and human emotions into uh clicking on or downloading the the uh email. And next uh we have uh the user did send that email he just created uh before receiving the uh hygiene tenant uh uh API limit exceeded. So we see that uh the uh the compromised user

or the attacker did send this email to 118 uh users uh before hitting the uh yeah the API limit. Special shout out to the to our threat hunting guys who are our first responder to such events like this and uh they do a really really great job. They do a really great job at at at Permisso and yeah this was a AI generated uh AI generated photo so it didn't look good so I thought yeah just use the normal one. Next uh detection defense strategies. Um first before starting talking about how you should defend yourself, how you should detect this stuff, you need to have your locks enabled in order to see these things. And um it's a really it's

a really generous thing to say, but yeah, some some logs are not enabled by default and you always want to have them because the attacker clearly won't do that for you. The next uh the first thing is um enabling the unified audit log which must be enabled in some subscriptions the mailbox audit log in which is enabled by default but still you want to double check it won't hurt and uh also use some exchange online logs like get inbox rule or get mailbox out log to just kind of surf around what's going on on the mailbox. Next is detect suspicious login activity. Again, it's a it's generous thing to say because they say, "Yeah, no

Yeah, I should detect some suspicious activity." But still, I cannot go without uh saying it. So, u what is suspicious or what uh uh suspicious login activity? Uh what does that mean to you? There are million ways, not million less, but yeah, there are different use cases how you deem to to find a a login suspicious. I just threw a bunch of them here. Some of them are uh geob based anomalies. So impossible travel login from like uh impossible geographic distance location. So if a user logged in from Kosovo and lo next time it log from I don't know let's say London uh under 30 minutes you know that there's something going on. But still you need to do more more

research on that because technically you could be using a VPN. But yeah, that's another another talk. A first time country or maybe unusual geoloccation for that role. And you always want to do some sort of baselining based on the device and and client anomalies. Uh and last but not least is uh monitor suspicious network which can be your to exit nodes or commercial VPNs which are which are highly used by threat actors nowadays. And how to detect inbox rule abuse. Now um the first and most important thing is find the inbox rule. Next is see if that inbox rule uh has any filter or condition set to keywords. So this tells you that the keywords condition is the

most used uh type of condition. Let's say if that's the case again these are the keyboards. So uh we have six of them. And um yeah, if that's if that's the case, you want to see if this keyword looks suspicious. Again, we have shown some suspic uh suspicious keywords, but that can be a different case. So you you you are the one who who are the judge to what is suspicious to you. But yeah, in our case, uh suspicious keywords can be admin, MFA, reset, anything related to security or even invoice and payment. Uh if that's the case, uh if there's no uh set to filter keyboard, you jump straight jump down to the actions. Uh so is there a

delete or move to actions. So you know that um if these two are correct then the next step is just to kind of check if there are any suspicious activity prior to this rule creation and if there is that can be marked as true positive and if there is not you can mark it as false positive now I just uh uh saw that I didn't put the rule name but yeah another another key point is um check the rule name if that makes sense sometimes the user will just uh create a fake rule name which says inbox optimization or uh archiving old emails but what it does actually is doing is just um deleting emails. So you want to

be extra careful uh on that one. So it can be a key uh low-level indicator but not something to actually deem it as as suspicious. I went by fast. Okay. So the summary threat actors continue to target business email uh for various purposes. They're not never going to stop. And um next is configuring the necessary cloud login option where you can uh you should retain your logs. You can forward them and uh start querying them for uh uh to enhance your capabilities to detect these uh bad guys. And yeah, look out for suspicious uh inbox rules where stealthy persistence is known to be attackers uh is known to be uh attackers's favorite dessert and evading

defenders can be a major milestone for attackers. Uh thanks for your time. I'm 10 minutes earlier but yeah I didn't catch your breath. So if you have any questions, any brave soul to ask any question said the old friend

uh thank you for the excellent presentation. Could you maybe share with us your thoughts on where these types of attacks uh are going? What's new? What are some interesting things that attackers are doing in the cloud and cloud apps? And how do you see this evolving in the near future? >> Yeah, great question. So um I'm going to stick to only him inbox um instead of just go talking about the whole uh cloud apps but still yeah I think that u attackers love a new way or new research which has to which has to do with initial access like if somebody sees uh post exploitation tool they said screw it it's not it's not important or it's

not as exciting as an initial access tool. tool. But um I do think that um as I as I mentioned earlier um a persistence if you find a persistent way into um not let uh not uh actually triggering alarms for for defenders or just trying to to uh screw up with defenders and instantly also screw up with the with the user. That's a that's a a really interesting and it's a really uh I would say it's the best way for for an attacker. I don't know if that I I completely u did answer your question correctly but yeah.

Hey, thank you for the presentation. Uh the rules that you mentioned, they were new to me and they are amazing. I'm going to start using them. Yeah. >> Uh I have a question here in Kasur. Do you know if we have actors acting in Albania and targeting Albanian businesses? >> Yeah. And I guess I'm not the right person to speak about that, but uh I don't know. I'm sure they they are but um yeah I'm sure they are. It depends like I'm not the right person to talk about that but yeah we can we can chat afterwards not on live. Any any other question? >> I'm not sure.

in and what you saw with the the the logs, do you normally see commodity based thread actors using those or do you have y'all noticed like real apt also using those types of filters as well? >> Uh I guess so uh I have a completely another resource related to inbox rules. I won't spoil it but um I think that uh as business email compromise are are growing there are definitely uh new ways into leveraging inbox rules like for example uh um if you were in the at depot presentation and aian about skyscap if you're using different ways so you can create inbox rules in three different ways you can leverage Microsoft graph API you can use the

powershell exchange module and you can use the the UI. Now if um you do this uh create a inbox rule in all three of them, there will be like small minor differences. So I think attackers are starting to understand that um there will be and there are differences between using an SDK using the u uh command line tool and also the u the UI. But yeah, I don't know if that does answer your question, but yeah. Yeah, it was one of the things like we noticed that a lot of like people trying to just steal money or like you mentioned the invoices keyword and a few other ones as well. Multiffactor authentication or just security alerts in general to try

not to tip off the user that they got compromised for example. Um but we've seen both like commodity based and nation state. But like from a practicality perspective on the detection piece enterprisewise, you know, you could be sending those logs to a SIM and an alert on the SIM itself. Let's just say a smaller company that doesn't have a SIM. Like in your opinion, if someone wants to implement what you're suggesting and detect on these logs, what platform would be something that you would suggest? like is it you know in Azure if you're using exchange or what would you suggest from like enforcement of these? >> Yeah. Yeah. So um let's say you are a

small company you don't own a seam or you're not uh you cannot afford one. There are lot of open source tool who do uh actually uh have some common TDPs about this one. Uh I did mention cloud grappler which is a detection framework and it actually has the ability to um find some of these uh malicious inbox rules and with some TTPs or you can use cloud tail another open-source tool developed by by our uh colleague but um yeah I think this there might be also other open source tools who uh can do the same thing.

Uh that was a great presentation. I just uh had a quick question about the effectiveness and how early on the stage these kind of problems can be detected and uh fixed. uh because let's say it's also on the potential danger of these Outlook breaches because let's say there's a a threat actor which actually has gotten access to the has breached the the Outlook uh mail and but let's say he's he works really slowly. Let's say he he's doing the recon really slow like a grandma in a wheelchair and he's just looking around and uh just finding and just waiting for the right moment to get the right information. >> Mhm. uh how effective you think these

new these inbox rules will be into actually preventing that and getting him in the early stage. Uh I don't know if inbox rules are the for example if an attackers just snoops around and reads emails there's not much inbox rules can do uh but uh yeah I think just doing some sort of baselining based on how many like if you're uh if that specific user has created an inbox rule which is a deletion inbox rule you want to do some sort of anomaly how many times has that user created an inbox rule. Fine. 10 times. Okay. Has it always been a delete inbox rule? Yeah. All 10 times. So that you can mark it less suspicious. But um I think what

you're asking is more about on the initial access phase where how you can detect an anomaly or anomalous um login rather than detecting an inbox rule. But um yeah.