Did You Say Millions Of Sessions? How Cheap Kits Fuel AiTM Attacks On Microsoft 365

So, I'm Joshua Ross. I'm a senior threat analyst for Sofos MDR. Um, I've recently been involved in tracking some Microsoft 365 adversaries, specifically for adversary in the middle and fishing as a service. And I've also been getting into detection engineering a little bit as well. So, in this presentation, I'd like to share my findings and what the research has shown and show why they're able to steal millions of sessions a year and do billions of dollars in damages. So, yep, that's the theme. Millions of stolen sessions, billions in losses. It's not necessarily that the attackers are getting smarter, um, that they're developing groundbreaking technology. It's the fact that a lot of automation these days just allows you to

industrialize these specific fishing kits a lot easier. and adversary in the middle is one of the most common used um kits to enable business email compromises at scale. There's some data sources. So, luckily enough, we have some leaked kit data that I'm able to present in not all of it, but some of it to everyone today. Um some recent takedown artifacts. If anyone's following the fast world, you saw that there was recent sieges for Raccoon Office 365 and they released a lot of nice details about that. and then as well as some you know open infrastructure signals or your OSN sources and items like that and some anonymized telemetry from my investigations. [clears throat] So after this presentation um for the

people that weren't at the other token flare event some of the others uh you'll have a greater understanding of adversary in the middle and fishing as a service um an understanding of the global scale and impact that this has against N365 tenants. You'll get a nice little detection map. I couldn't do everything cuz that would be a 40hour speech, but you'll get an overview of how your detections can map to the kill chain of these attacks. You'll see some recognizable artifacts you'll be able to take back to your investigations, take back to your threat hunting and intel and be able to be like, "Hey, I saw that one. Let's uh kill it." And then as well

as some case benchmarks, so real life insights and some live insights as well. So, the big picture, uh, last year's FBI IC3 report showed almost $3 billion in total damages and losses in business email compromise from around 20,000 incidents. Microsoft reported approximately 146% growth in adversary in the middle attacks. Um, however, in the latest report, I didn't see a percentage. So, that was in 2024, so I'm not 100% sure how much it's grown this year, but I can assume it's probably on the same amount. And on top of that, they said there was around 40,000 adversary in the middle attacks per day. Now, that's not just for Microsoft 365, that's against the global stack. So, across all your

technologies, other SAS, um, whatever kind of authentication methods they're trying to target. So, what is vers in the middle? Um, again, if you're at the token flare one before, that was explained, but simply, it's basically you're trying to authenticate to your authentication service. Everything looks and acts exactly the same. There's an adversary that's either sitting in the middle of that, hence adversary in the middle, and they're either intercepting your tokens through a form or they're proxying it directly from the Microsoft communications to their server. And then you accept MFA like usual and then the attackers in, they got your session, you get redirected to something like office.com as was mentioned before or like Rick Ashley if they really hate

you. Um, depends what they've done with their redirects. So why does it matter? So, as mentioned, it steals your full sessions, your full tokens, um, not just your credentials. So, they're basically bypassing your MFA controls unless you've got decent conditional access policies. On top of that, it enables fraud and espionage, enables your business email compromise, allows for somewhat easy and stealthy access to your environment depending on how good the kit is. And then as well as long dwell times. So I think the median time before a business email compromise is first detected by a signal and that could also be a low-level alert was approximately 5 days. So they've had 5 days in your business emails um whatever

other cloud apps you have before they even first get detected. So this is a bit more of an in-depth diagram. Uh sorry some of the text is a bit small but basically there's two main types of adversary in the middleware kits that we see in the wild for N365. First one being reverse proxy. That's the most common one. You'll see that as your evil genix, evil proxy, evil everything. Um, what this does is it basically, hence the name proxy. You still communicate with the normal Microsoft 365 service from your browser, but at the end when you generate your session, you go through MFA, you get your token, the attacker ends up authenticating and using that final

token in their service context and it goes to the attackers panel. Now the difference between that and a synchronous relay kit is basically your browser this time. So the fishing page, the fishlet is just a fake form. The information that you're putting in, your username and password is being relayed to the attacker's backend server. And then the backend server itself is the one that's authenticating communicating with Microsoft. So why does that matter? Well, two differences is in reverse proxy, they're getting your browser context directly. So that's why a lot of these stealthier kits use reverse proxy mechanisms because an Entra ID, you're just going to see the same user agent as the victim being replayed in Entra and

the only difference would be the attacker IP. But attackers are getting a bit more clever with that and they're being able to capture your IP and be able to use a similar ASN or ISP to you, right? So they're trying to bypass your conditional access policies, etc. Whereas synchronous relay, if the kit producers are lazy, which they usually are, you're going to get your classic static user agent string um from most people in here that do business email compromise investigations. That's similar to Tycoon, which is your Axius one that's been everywhere over the last couple years. And that's why that's a static detection point. This is kind of the in text in case the diagram was too small. So again the main

differences is just there's no real attack or sorry user device context going for that synchronous relay unless the form itself is capturing that. Um whereas reverse proxy it's almost like a onetoone to Microsoft but with someone in the middle of those communications. So real infrastructure example. So what does it actually look like for the user? So a lot of the times you get to your first Cloudflare and every time I see Cloudflare now I think it's sus. Like even if it's legitimate website that I've gone to millions of times I see that I'm like I'm cooked. But from there you just get your normal Microsoft signin acts and looks exactly like the Microsoft signin except there might be a

little difference in URL depending on what the delivery mechanism is. From there you get your usual MFA request as normal whatever you set it up with to your phone um to your email hopefully not email these days but yet mostly phone authenticator app etc. And then usually after that you're either redirected again to another sign-in page or again like office.com or whatever. They decide to do the redirect and you just think, "Oh, that's weird. My browser refreshed. I'll log in again." And this time you're actually logging into the normal Microsoft after. So kind of tricking the user and making sure that they don't know they've been fished, so they don't report it to their IT teams.

So these are just some snippets of what it looks like on kind of the browser request network layer. So, as you can see, the request URL is actually coming from a domain that's not your classic login.microsoft online. There are legitimate use cases for this, but most of the time it might be a proxy attack. You can see that they still have the get credential type being sent out. The post request to Microsoft is still the same, but the referer is coming from the attacker instead. You can see it still generates the same cookies and basically all the same device information during this attack. Now, for synchronous relay, this one's a little bit different. So, you can see

maybe in the screenshot, yep, you can see next.php. It's basically that's the form that's on the attacker's backend server. You're filling in your username, your password, and then they're doing kind of the MFA component from their backend server side instead of you, but you're basically logging in for them. You can say you're doing all the work for them. Um, but at the end of the day, it's going to be the attacker's IP, the attacker's browser information that gets the request and has the relevant enter logs. So, to recap, legitimate versus fake flow. So, at the top, you've got your generic Microsoft, you can see it's usually login.microsoft.online.com. And you can see the middle one is

reverse proxy. It's the same thing except you've got the attackers domain there instead. So, that's something you can keep an eye on in the URL bar. But let's be real, when I log into my Microsoft, I'm not looking at the tiny URL bar all the time. So that's something where you can start thinking about detection controls for that or marking your usual login portals with something um so that when someone goes through your same portal or theme as you, it goes, hey, this is an unusual one, but that's quite a difficult detection point as well and requires a lot of work. But then at the bottom again, it's doing the post request to the next.php file, more of a form

instead of a proxy, hence relay. All right, let's get into the fishing as a service ecosystem. So, fishing as a service, for those that don't know, it's basically just software as a service, except they're giving you a bunch of fishing tools. Um, you'll sign up to it on the dark web, on Telegram, or something like that, and it comes prepackaged with all the toolkit that you need to bypass industry standard defenses. For example, this is some screenshots from my lovely friends Raccoon Office 365. um they were very very noisy which probably led to them you know getting over 300 domains seized within a year but they allowed us to have a lot of insight into the actual ecosystem

itself. So some of the main things about this is when you proceed to the dark web forum or the telegram you get a pricing list. Now, this price on this is quite important to remember because it's about £300400 for a month that comes with a full adversary in the middle kit, fishing services, help desks that allows you to bypass industry standard MFA for as little as £300 a month. Some services are even cheaper and so on. On top of that, you can see on the third screenshot, adversary in the middle is a service. So, basically, that is what message you would get to your email or Telegram when someone logs into the portal. You're getting the user, the

password, the IP, the city they're from, their user agent, and usually attached the cookie as well. You can see that's quite a lot of good information. If you have a smart attacker, they're going to like easily follow what ISP login. Maybe they'll buy a residential proxy or just a residential IP. They might have botnet setup. Like it's up to the attacker for how stealthy they want to be. From there, though, how does it work? So, buy a portal flow. I've mapped this into five main steps. So the buyer is interested, they contact either an automated bot, but in most cases a bit more of a um exclusive environment. So it's a bit more going through dark web forums,

getting trusted first and word of mouth. From there, they'll interact with a bot um either through Telegram. I think sometimes Discord had it as well, but Telegram is the main one. Um they'll be able to view the plan, subscription, prices, and also anything extra the bot provides. Then you get the panel deployed to you. So that's a panel. It's kind of your central where you get to configure everything. You can deploy your kits. Um you can pick up your URLs, create fishing attachments automatically. It's basically kind of the brains of the operation. And then from there, they deploy it to your fishing lur, which is most of the time ends up being what you see. And then

they send it and deliver it to the victim. And the victim accesses it and gets their session stolen. That's kind of the flow. So now let's compare this to an actual live actors flow at the moment. Um, just to note that the artifacts are from 6 months ago because we don't want to use the ones right now to tip anyone off, but this is basically an insight to how Storm 1167, otherwise known as Flower Storm works and operates and why they've been extremely successful over these last few years. If anyone's a real big nerd about this stuff, this is the same people that were called One Drive X a few years ago. The buyer. So, sadly, I never found the

actual buyer flow. Um, so the first step for this, I couldn't find the exact user that they've been messaging or the exact dark web onion site. However, I did find the bot on Telegram and got some insights on this. So, basically, it seems like the contacts have to go through word of mouth, an exclusive society, or an unmonitored dark website. They haven't seen yet. They make a connection to the bot and they get given a chat ID. Now, this chat ID is very important for these next few slides because if you can see the chat ID, I wonder if I can zoom in. That chat ID there 7526960 is the same chat I

is the same chat ID that ends up getting registered to the backend domains. So if you're in the intelligence sector and you're tracking their communications, you can just see when someone registers gets a chat ID to the bot and if you know, you know what TLD they're using, what domains they're using, subdomains, whatever, you can just go, well, it's going to be chat ID. Blocked as soon as they register. So that was a very important step for maintaining on top of this actor. Sadly, I think they realized their mistakes and they're not doing this the same anymore, but they might be doing something similar. Now, the bot itself, so this bot isn't as noisy as some of the other bots, like

they didn't have um all your subscriptions getting listed and all of that through their communications, but usually it's initiated with a slash start command uh when they register. You can see a few test emails then making sure the bot's working. They can communicate with the supplier and things like that. You can also see is they do important broadcasts through it, which is one of my favorite ones from some leaked messages is the owner of the service got their Telegram account blocked and they're trying to reach out to the rest of people and say, "Hey, this is my new account name," which sadly I have to redact. But you can see that it's mostly used for important

broadcasts. And we've also seen kind of um it being used as a help desk as well, like, "Hey, my link's down. Give me a new one." Or, "Hey, the domain's blocked already. I want a refund. I want my money back." Um things like that. That's what the botch used for. Then the panel. So this is what the panel actually looks like when you pay for the service. Um for Storm 1167 specifically, the deployed kit kind of comes before the panel. So it's a bit of the other way around for that step, but we'll get into that soon. But basically, the panel allows you to create your fishing links. So that's your fishing lur attachments. Um it even lets you

create um you know like your actual attachments to the email as well. to HTML's PDF and even if you remember from about a year ago the sneaky create an SVG as well that can be used for the fish. Uh on this as well they'll have the login page um how many people have visited your fishing lurs and the code on the left or your right shows that when someone logs in their emails posted their passwords posted and the cookie. So you can see that's a onetoone line that's some leaked source code that they gracefully gave us. So it gave us a lot of insight into exactly how that panel works. Moving on the deployed kit and the

infrastructure. So in this case the service provider is responsible for those backend domains since it's a synchronous relay. So we found at least that they used to and still do a little bit now is they use a single cPanel server to deploy a bunch of domains. This means if you get on top of the intelligence and you're able to track a records and domain changes to that panel, you can see as soon as they register a new domain, it's was quite easy. Um it took them ages to realize that they need to put Cloudflare or something like that to protect it. But that gave us about a year's worth of tracking opportunities to proactively block almost everything apart from maybe

the C panels we weren't tracking. From there, they also developed this section where they would do the user identifier, aka the chat ID and the stack identifier from the service provider to a 10-centent cloud where they hosted a fake JavaScript. It masquerades bootstrap.mmin.js and that's actually what loads all the differences in the page forms. And again, because they use that user identifier, you could find that openly online through OS in sources and be able to block it straight away because it was just 10-centent cloud. They weren't putting it behind any other DNS protection. >> [snorts] >> Now, how does it work for the actual fash user? So, basically, they deploy their fishet like you saw in the

previous screenshot. Someone visits their fishing alert, types in the credentials, and it gets sent to either an email address, to their telegram, or to the panel where they can then copy that cookie and replay it. Uh on the the uh screenshot there as well is the actual files that are deployed to the backend server. So got leaked enough where we could actually have insights into the exact files that they were using and exactly how it worked which allowed for better detection efforts. Now for the victim, so basically in that next.php file in the previous section, we can see that they have some code in there which basically sends it to the bot token which is the master token. If

you have that, you can track all their messages um and then to the chat ID specifically as well. And they'll get a little message kind of like on the right there. and also the cookie file. So they can just copy paste that cookie file and go ahead in and compromise your email system. All right, so that was basically adversary in the middle and the faz ecosystem. But what about what happens afterwards? What happens in a business email compromise once they have your credentials and once they're into your system? So the post compromise chain is usually the compromise, right? So session stolen, session still has to get reapplied because this is automated, right? It's an automated server that's

putting the login. It doesn't mean that the actual user or hacker themselves have logged in quite yet. So, they have to reuse that session that generated and go back in, which can kind of develop a nice detection point as well because if they're not smart enough and they don't replay the same user agent string, don't replay the same ISP, you might start getting your impossible travel alerts, you might start getting your multi-operating system alerts and things like that. But if they're smart enough, then it will just look exactly the same. From there, they'll usually use that business email compromise to conduct a bunch of fraud, which we'll get into a bit more in a second. And sometimes

persistence as well. So, an example of persistence could be just adding a new authentication method, a new MFA device, and just sneakily logging in during the business hours. The impact pathways mostly is your business email compromised fraud as we quickly went over before. So, intercepting legitimate payment requests, um, you know, some fancy, you know, the Amazon gift cards like I'm see, I need an Amazon gift card. Um, but then anything scary to completely redirecting million-dollar invoices. Um, from there they also use it for data theft. So, as we said, the more stealthy attackers can actually sit in your environment using the token for up to 90 days. It's refreshing. They have MFA, maybe even years. They just slowly stay

in there ex data and you never find out about it. Then you got internal and external fishing. So maybe they've got into your environment, but you're just like maybe HR or something like that, but they want to target CEO. where they want to target finance. So they go, okay, I'm going to find your contacts, find the specific users, and I'm going to jump across and move to a different user base to gain more trust in the environment. And then external fishing as well. It could be, you know, I didn't want to target Sofos. I wanted to target CrowdStrike instead. So they use the trust between those companies to jump across. And then finally, you got cloud

identity abuse. So that's just kind of various other things they can do. They can maybe impersonate you, um, just read some information to target you. or the individual through different means or they might try and pivot to on premises and stuff like that. It all depends what the attacker's goals are. So this slide is kind of business email compromise in action. So this is showing from kind of like a telemetry detection standpoint exactly what happens. So you can see that a fishing alert gets delivered and the first one um they worked really hard. They want to claim their bonus. So they click on that, they fill in login. They want to view the file but the session is now stolen. From

there the session gets reused by the attacker but because they were very sneaky it comes from the almost the same ISP. Again the same user agent string the same browser context as the user and thus does not get flagged as impossible travel which does not get flagged as an anonymous signin. From there they'll access the mailbox stealthily. So anyone that does business email compromise investigations and entry will be familiar with mail items accessed. So they do that stealthily over time. In this example, there's been a burst which can kind of detect, but if they don't do a burst, they might just access two or three a day and you're not going to see it. It just looks like normal traffic,

normal business hours, nothing seen. Then from there, they find the conversations they want to hijack. So, they know your contacts know, they know what you're up to. So, this example, they decided to find an invoice in the draft folder of significant impact. And then what they've done is they've edited that invoice, used the trust between the other company and changed and redirect any further payments to the attacker which achieves financial fraud. From there they cover their tracks and this is where most of the detections happen. They create an inbox rule. They use special characters or something like that. Dot dot dot very similar one. A lot of detection controls pick this up. Or they're a bit more sneakier about it

and they just say anything with invoice gets moved to deleted items gets moved to RSS feeds. Right? So they're trying to cover the track, make sure the user doesn't know what's going on in the background. And that's also, as I said before, that's usually where this gets detected. All of the rest of this chain, the impacts already happen, and it's only detected right at the end after the effect. So I talked a little bit about this quiet data theft and dwell time. There's some quotes up here as well. Um so basically again if they're just reading access they just want to you know bit more espionage want to learn about your environment slowly expiltrate information they'll just access a few

targeted emails per day and that won't even create an anomalous log entry. They won't create anything. Um they're just sneakily in there. If you didn't catch them at sign in they could be in there for months at least and specifically taking documents that they're after. Now around less than 8% actually gets detected by technical controls. What does this mean exactly? I mean that anomalous sign in the inbox rules and whatnot. Most of the time it's actually reported after the fact because once money's involved that's when we start seeing the movement and start seeing things getting caught. You know follow the money very common. That's also when uh a lot of the tape downs start coming

in as well. Then on top of that, said this before, median dwell time 5 days, right? And that's just from reported sources. Like if you don't know they're in there in the first place, I can assume that a lot of dwell time might push the median higher. Let's move on to some impact studies. So this is the real world impact that we have from research and open source telemetry and the takeown artifacts as mentioned before. Let's have a look how much damage one of those cheap $300 kits actually does. So, enter Flower Storm. So, over a period of 6 months, I was able to get in-depth tracking um through various means and we found that every

single month because they had some leak buckets, there was 1 million page views. You know, this might not be exact um actual 1 million individual humans visiting per month, you know, bots, scrapers, etc., But still quite crazy how much this kit is getting traction. Over a period of 6 months through leaked messages, we found that there was approximately 160,000 user email password combinations leaked through messages. Now, not all of these messages were real passwords because it could be a lot of researchers like myself messing around um with their login pages and things like that. But that's still quite staggering that even if half of that was true, that's quite a lot of damage in 6 months. Um, on top of

that, we found they targeted over 60,000 different individual organizations, which is quite a lot. So that's why it's a software as a service, right? It's not your AP attacker targeting one sector. It's just fair game from there. It's whatever their goal is when they buy the service. >> [snorts] >> Now, out of those around 160,000 emails and passwords, we found 23,000 cookie attachments in 6 months. So, that's 23,000 instances where they bypassed MFA. Doesn't mean they got in because conditional access policies, but quite a lot, right? You can remember that the FBI IC3 before was 20,000 reported incidents in a year. Whereas one service right now got 23,000 files in 6 months. So almost up to

50,000 session files from a single threat actor. And on top of that, there was about 500 operators using the service at any one time over that period of 6 months. Now there's some geographical distribution here. Um, this could be, you know, a little bit skewed because it's based off on, um, you know, also what our investigations were based on, but United States was definitely the heaviest and UK coming in at second at 5%. So, not as bad as US there, but if you count the numbers, that's still quite a lot of compromises in 6 months. And on top of that, we found a second bot that we couldn't get as much info on, which possibly doubles these stats.

So, all of this could be doubled, but I can't confirm that. I didn't have as de in-depth access. So, Raccoon offer 365. So, they didn't have as much of an impact as at least reported, but um I couldn't verify these details. This is based on just evidence that's out there in the wild. So, basically, they managed to steal around 5,000 credentials, they said. So, I'm not sure if that was full sessions. Um they targeted around at least 2,300 organizations and 20 plus of them were healthcare organizations. Right. So, bit brutal. um some of the people they target. We also see non forp profofit being targeted a lot as well which is quite sad because they can't afford the same industry

standard defenses a lot of the larger organizations. [clears throat] So infrastructure and capability. So I believe their joint effort seized 338 domains quite a lot in a period of around 7 months. They tracked 100 to 200 active subscriptions to their telegram service and tracked $100,000 worth of crypto payments. And that's $100,000 worth of crypto payments to the attacker for the service, not from people's financial crime. On top of that though, they found that around 9,000 fishing emails were sent a day per user. So absolute insane amount of fishing emails. So you think that from your delivery detection standpoints, your email gateways, is it going to just have one of those 9,000 slip through eventually? Probably.

On top of that, some more insights cool about this is this is one of the first tracked efforts where they're starting to introduce AI into the fishing as a service ecosystem. This one was just kind of a mail check. It's just verifying that the domains exist and no one's messing around with your credentials. It wasn't anything groundbreaking, but still interesting. That's what they're starting to move into. Global impact. This is quite big. So we saw there was around 40,000 adversary in the middle fishing attempts per day across all stacks reported by Microsoft 365 and their intelligence. Based on the findings and the scale of Storm 1167, recruiting Office 365 and others, we saw that Flowers themselves

stole at least 120 sessions per day, possibly doubled. They stole what was it 16,000 credentials, 160 over the period of 6 months. But they only had about a 5% share of the entire adversary in the middle fishing as a system ecosystem. So from detection rates, from domain registration rates and intel findings, they're only sitting at 5%. So you can times all those stats by almost 20. From there, we find that the reported daily adversary in the middle attacks or attempts to attack on Microsoft 365 is around 18,000. So across all stacks, Microsoft 365 is almost 50% of targeted activity and that's why business email compromise ends up causing so much damages and losses and is such a hot topic at the

moment. Uh detection gaps and strategies kind of the final section. So I'll go through the kill chain for these. I can't go too much in depth cuz that would be a whole 40-minute speech again. But basically there's four main steps with the bver in the middle kill chain that you should remember. It's the resource development that deployment of the tools, the acquisitions of domains, the creations of URLs, the creations of the fishing kits, etc., etc. The telegram channels spinning up, um, all of that good stuff. Then you got delivery as well. So that's when the tool kits actually delivered, the fishing alerts delivered to the user for fishing emails, etc. Then you've got the sign in, which is where you really

want to stop this at. That's when they've actually intercepted and signed in to your tenant. and then post compromise the most reported everything they do after that. So again some few things you can get for resource development. So domain and registering patterns they're very important to track because a lot of the times it's scripted and they'll reuse similar domain names similar IPs and similar chains back and infrastructure overlap. If you go back to my talk about the C panel that's exactly the kind of thing I'm talking about. It overlaps and you can track multiple domains for one IP and pre-live kit artifacts as well. That's uh when you've got a bit more intel on them and you're able to track

them at the source. For example, this is one of the cPanel IPs. We can see using virus total that there's multiple of those. Remember I said chat ID combos are being registered or to one IP. And what happens is when they use the fishing alert when you enter your form, it has to communicate to that backend IP. So if you have that blocked at the network layer on all your users devices, the fishing kit's not going to work. or even better if you're proactively take down their backend domains, the fishing kit doesn't work and they lose customers and lose trust. So that's why if you're able to legally track a Telegram chat used by the attacker using the global

API key, you can figure out when the user ID is registering, when the chat ID gets registered, and just block it straight away. It certainly won't function anymore because a synchronous relay and relies on the back end. delivery. So quick into that. That's all your pathways, right? So emails, SMS, QRL, QR levels, um all of that good stuff, but as well as redirect infrastructure. So this was mentioned also in token flare. That's sometimes you'll have a redirect at the end. Um and also beforehand such as the Cloudflare turn cells and things like that. So that's all behavior that you can track as well as the actual landing kit page like behaviors. So we saw before some screenshots, it loads all

these relative files and they're almost static. very little differences in these. So if you could have browser inspection and you see those files, you can just block that off straight away. Kill it at the source or use those files to track for new domains. For example, there's a collage for everyone's favorite docuign scams that go around. Um they're all pretty much the same templated blur just reused and that's because they get generated online from the fishing kits. So on the right there we have communicating files. These are about 500 communicating files, HTMLs PDFs etc. etc. communicating to one single IP address. So, you can start tracking those delivery alerts that you get in your email gateway if

you're a researcher. Find out where they've been communicating to and then you go, well, I've got the fishing IP. I can block that server. Now, for signin, sign in is the important part. That's where you want to make sure you start detecting it. But sadly, is a lot harder to detect with the stealthier mechanism these days. So you got your pre-off before the ORF even happens. You got those get credential type prevalidate checks going out to a non-Microsoft domain. Um maybe with browser inspection you can get that but if not it might be a bit difficult. And you've also got again the PHP scripts loading. You've got reverse proxy behaviors and sometimes websockets as well going through all of that can be

get by browser inspection network layer telemetry and things like that. Then [clears throat] you got your header and fingerprint mismatches. I won't go into TLS and J3, but basically before we mentioned that your user browser specifically for synchronous relay isn't the browser that ends up requesting for your authentication, right? So there's a mismatch there. And then your entry session indicators finally. So everything that you get when you investigate or detect an entra ID. For example, um sorry for trying to fit so much on this slide, but basically you've got the pre-off anomaly there. So you can see the get credential type that can be detected by browser inspection. You got the bootstrap.mmin loading. Again, you can track those files almost

statically or for just a portion of that file. And then your header and fingerprint mismatches. So you log in through your victim user agent. So whatever your Windows normal Chrome is, but then the entry log ends up logging in with Axios or a static user agent string and an IP completely out. That's when your conditional access controls start coming into play and as well as the session metadata as well. So same thing reverse proxy itself bypasses this by using the browser context but still the server IP that connects whereas the relay attacks you're going to get static user agents unless they're smart enough to change that in the future. For example, zooming into this, this was a

attack from a reverse proxy. You can see that the IP address that it's actually posting requests to is the same IP address in the entra ID logs. So that's a good point where if you're able to track different IP addresses through OS in, you can just start saying, well, I know they're coming from this ASN this IP. Let's alert when there's a login from there. Or if you have an even better system where you can do baseline anomaly detections, which is a bit more rare, a bit more expensive, then you can be like, well, look, that's an IP that's from Cloudflare or something like that. The user shouldn't be logging in. They should be logging in from a residential

ISP. Finally, post compromise. So, I don't want to go too much into post compromise because that's the most heavily reported. That's a whole another sector, but you can start thinking about some of the stealthier things you might want to start detecting, right? If you can't get the sign in, you need to get what happens next as quickly as possible before they execute their impact. So, mailbox recon hard to detect, but a lot of the times they'll do automatic scanning. So, mail items access bursts might hop up. Um, you can have, you know, your little um can't what they're called, honeypot files, whatever of fake password files and stuff like that that match. Hey, uh, someone just queried

this file, but that's a fake file. and now I know that someone might be in the system. Whereas when you start getting into persistence and manipulation, that's when detection start kicking in these days. That's your inbox rules, that's your MFA registration changes, your spear fishing and whatnot. [snorts] Detection strategy. Now, you don't have to follow this completely, and it's a massive array of items, but this is basically what your defensive stack needs to look like to kill adversary in the middle at every chain. That's all I want you to think about right now is how much effort you have to put in to detect, prevent, and stop adversary in the middle attacks in Microsoft 365.

Now, let's have a think about this. your MFA deployment for every user not that expensive a lot of the times free but there are still hidden costs like you need an IT admin to maintain your enter ID your conditional access policies and whatnot so that's going to at least cost you you know quite a few thousand a month and then when you want to start putting fishing resistance stuff in F22 keys you want proactive detection you're adding thousands you might be spending5 to£10,000 a month on a defensive stack like this at least whereas the attacker bypasses it with £300 and little to no experience. A script kitty with a little bit of money is bypassing £10,000 a month worth of

detections. Crazy to think about. So let's have a look at some detection gaps. So one early infrastructure tracking. This is more difficult, right? This is up to the researchers, the intel communities. um your intel feeds, your reports, URL scan hits, uh census hits, virus total hits, etc. Um that's where you can start blocking a bit of the chain. But again, it's hard because 9,000 fishing emails sent a day. Um I don't even want to know how many fishing sites get brought up a day. Possibly hundreds of thousands if not millions. So you're always falling a bit behind there, which is why it's important to have those specific mechanisms I explained before for tracking like the

backend redeployments, getting the chat ID at the source for the telegram, shutting it down straight away because that's hard for every organization to track every bit of intel. So authentication should not equal a compromise. So that's another pointless detection gap right now is you have that reverse proxy going through and authenticating using the session that should have gone to Microsoft yet they're still able to get it and use it. Then for synchronous relay it's the same thing. They're still able to go into the attacker context and authenticate unless you've got extremely strong conditional access policies or higher license levels. You might not detect this a lot of the time. Like not every organization has F2 keys, devicebound authentication

and things like that. So it ends up being really hard to detect, especially if you don't have something like an XDR sitting analyzing your audit logs. On top of that, the session context is not continuously evaluated. What do I mean by that is that the attacker ends up using the same session for a multitude of like login. They might log in periodically through days and then that's not tracked because the first authentication isn't tracked. It just looks like normal authentication activity. And that's because a lot of the audit logs especially for the free standard and enter ID doesn't have all that nice context. It doesn't say hey you know they offer this specific token from this

specific IP or server. It's usually just browser context right user agent string and device information. And then of course your low and slow activity. So that's your long dwell times them only reading a few email accesses a day. If you don't get that sign in initially you're not going to detect this at all. And then finally again what was that that 8% figure over 90% of detections end up happening after the impact. So something to think about is how we start detecting that sign in or coming together as a community to take people down quicker. So a simple detection workflow I won't go too much but basically you want to alert right you want to alert on those

signins as quickly as possible. Start thinking about this. If a user ends up using a VPN and a new laptop, can they off into your environment with a detection flag or what if their ISP slightly changes? Will that flag a detection? Probably not. Is that user device bound? Do they have a F2 key or do they at least have MFA? So, a lot to think about how to start getting these signins and what your defensive stack is capable of already. And then correlation. Again, you have to correlate these alerts. So maybe there's a sign in. It's from a similar ISP. Maybe the user's just in Starbucks today, but they've started accessing a larger amount of mail items. They start

accessing a larger amount of specific types of emails and they've started trying to send maybe a suspicious amount of emails. So your spam attacks and things like that. That's where that correlation starts coming in. If you can't get that sign in, maybe you can get them at the recon side. Then response, this is really important as well. So response is like you get that sign in, you get that alert, but are you blocking that automatically? Are you kicking them out? That's a hard one to come together though because you don't want to make the user mad. You don't want to just kick everyone out all the time, but at the same time, you want to stop this

early in the chain. And then hardening, start thinking about passwordless authentication, um, fo2 keys and items like that. >> [clears throat] >> So, for those that have Microsoft quick visibility check, if you're on E5, you're likely good against a lot of vers attacks, except for maybe the very stealthy ones. If you're E3, it's usually not as good, but it picks up some items. Um, especially if you have maybe like an entry ID P2 add-on or something like that, you start getting impossible travel. But business premium, business standard, you know, a lot of the smaller organizations are a lot more vulnerable. And that is where we're getting at the point where if we can take them down at resource development,

then we can also protect the smaller organizations. So key takeaways if you get anything from this presentation is that adversary in the middle breaks the trust model. Your valid MFA sessions can be reused by the attacker. Extremely easy these days and bypasses traditional alerts. Second is most damage happens after the signin. So we need to stop this attack before the signin happens. And the third one early detection beats perfect detection. Like if you're still got an 80% confidence that this might be not a user activity, just have an automated response action to end it. The user might get slightly annoyed, but maybe you've stopped a multi-million dollar business email compromise by doing so. There's some references and further

reading, but that's it from me. Thank you for all your time. I know it's been a lot. [applause]

>> [applause] >> Thank you, Joshua. >> Thank you. >> That was a great great talk. Very insightful, very informative. I'm sure you'll have some questions. Has anybody got any questions? Okay, there you go. >> Hi. Um, with Microsoft RO and others rolling out device bound session credentials, how do you think that will affect this? >> So, devicebound session credentials like tying it to the device that will help a lot. So, as you saw a lot for the reverse proxy synchronous relay is that it's not actually coming from that user's device. They're able to steal the browser context, but not the device context. So, if you have very decent devicebound access controls, it will stop those types of bvery in the middle

attacks. The only way they can maybe get through that is if they have access to the device itself, if that makes sense. that. >> So with device bound session credential you've got the cookie which is stored by uh use secured using the browser using the TPM. >> So the cookie is unable to be stolen. >> Sorry >> the the cookie the the session or cookie is no longer able to be stolen. >> No because it's coming from a different device in fact. Yeah. Yeah. Exactly. >> Anyone else?

Uh thanks for the talk. I thought it was really good. Um I was just wondering with your slide um a few moments ago about the different licensing levels for Microsoft E5, E3, Business Premium, etc. Is there sort of the the quality of visibility in that second column? Is that based on sort of out the box and default configurations or is that just that the higher tiers provide you with more capabilities to configure better visibility for yourself should you have the capability in house to do so? >> Yes. So a lot of these um the main configuration starts coming in from Entra and conditional access policies but a lot of the lower licenses you don't get that kind of same um in-depth

configuration you can do that conditional access or device bound and things like that. So usually like maybe if you have entra ID2 or something like that you've got a lot more alerts coming in from Microsoft but a lot more availability to configure things more in depth in Entra. um the lower licenses you can still get away with a lot of decent conditional access. Um maybe you can roll out um different MFA or FTO2 um outside of just Entra, you know, using third party, but um it's just a lot harder and more costly, right? So you might need to go hire someone that's really good at this stuff instead and spend money that way because the

licenses give the same capabilities, if that makes sense. >> Yeah. Um thank you for that. It was excellent on the postbach stuff as well. Um, you mentioned you just answered it a little bit then, but what conditional access rules would you recommend in addition to MFA? >> So, some of good ones to have if you can get away with it or some even simple ones is like your geo based that's like good but not perfect. Um, another one is, you know, start thinking about your devicebound rules, your browser specific rules as well, like your, they only use a Windows device, so they shouldn't be logging in from a Mac user agent or an Axios user agent, things like that. So

things that are basically device- based, anything that's browser context based, and anything that's regional based if your organization allows it, are very easy controls you can start putting in now before you even think about FO2 and pass keyless authentication. I have a very good followup to that. Uh you mentioned not allowing signins from uh Mac devices and iOS devices. I work in nothing but Microsoft stack and we have multiple clients who have multiple users who only use Macs and iOS and then we run into the issue of not having any sort of visibility into those devices. So even if we wanted to corroborate uh sign-in logs with um uh device network events, the only things

that come through from max at least on device network events are things that fail. So how would we go about hardening from that standpoint? >> Yeah. And I think that's where the challenge lies is like because it's more of that browser context again, right? Um, and that's something that I don't have a really good answer for. And that's one of the gaps that happens is like unless you're going directly to like a registered device at Entra, like your users going to switch browsers all the time. Um, they might have just an update that changes the user agent a little bit and that becomes a lot harder to detect and that's where the more detection anomalies come from. Also combining that

sign in with an application as well. So maybe you have a user that signs in from Chrome all the time to Office Home, but then suddenly there's an Axios request or something like that to Office Home and that's when you can start capturing that kind of browserbound conditional access versus just who uses a Mac or who uses Windows. Like I think maybe you can get more in depth of Intune but that's not quite my specialtity. So I don't want to give you any recommendations that aren't true. But yeah, thank you. >> Yeah. Uh yeah, just on that licensing slide, uh sad to admit that I'm a bit of a Microsoft licensing enthusiast. Uh the capability between business premium and

E3 is exactly the same on Entra. Uh just as a point of reference, it's quite a cheap license. And on that point around in tune device compliance, you can that's the CA policy that that would block most um attacker in the middle. You can enroll a Mac device, a Windows device, or any device. And once you get that compliance, that's going to stop most of this stuff happening at all. So just and I know some people use J for Mac and I just heard the comment about Mac OS, but yeah, Intune is the answer to that. I can talk about in tune if any wants to afterwards. >> Yeah, sure. Um, >> all right, Josh, thank you very much for

your talk. Really appreciate it. Let's give him a round of applause, please, everyone. Thank you.