How to Test Adversary-in-the-Middle Without Hacking Tools

This webcast originally aired on March 13, 2025.

In this video, Michael Allen discusses how to test Adversary-in-the-Middle attacks without using hacking tools. He delves into the intricacies of credential harvesting, the evolution of multi-factor authentication (MFA), and how attackers adapt their strategies to bypass security measures. Michael provides insights on identifying weak MFA methods and offers practical steps to strengthen security, highlighting the importance of using FIDO2 passkeys as a robust defense against Adversary-in-the-Middle attacks.

• The evolution of credential harvesting attacks highlights the constant adaptation of attackers in response to security measures like Multi-Factor Authentication (MFA).
• Adversary-in-the-middle attacks leverage the attacker’s computer to intercept login credentials, including session tokens, bypassing traditional MFA security.
• FIDO2 passkeys represent a significant advancement in MFA, using public key cryptography to ensure that authentication is tied to a device the user physically possesses.

Highlights

Full Video

Transcript

Michael Allen

Okay, Hi everybody and welcome to how to Test Adversary-in-the-Middle Without Hacking Tools with me, Michael Allen. if you don’t know who I am, let me quickly introduce myself. I am a Red teamer and pen tester at Black Hills Information Security.

Currently, act as one of our Red Team practice leads and our initial access specialist on our ANTISOC continuous pen testing team, which if you’re not familiar with that, it’s basically a long running Red Team exercise against a bunch of customers all at once.

It’s a subscription service so it’s just constantly ongoing. And I’m constantly trying to come up with new ways to break into those environments and get us initial access into them in some way. In addition to my regular job at bhis, I also teach, I teach Red Team Initial Access, which I’ve got coming up at Kernelcon in April and Wild West Hack and Fest in October, and Real Social Engineering, coming up at our Red Team Summit next week.

It’s going to be online through Antisyphon. And Chris, who is just on the pre-show banter, he’s also going to be teaching there. So looking forward to seeing everybody for those events. And if you’re interested in the Adversary-in-the-Middle topic that I’m talking about today, that topic specifically and teaching how to do that attack as the attacker is something that I teach in the Red Team Initial Access class.

I’m also on a little bit of social media. I post pretty rarely, trying to get like posting more frequently. But honestly I’m, I’m not on there a ton but I do have my social media handle down at the bottom. White Rhino, I’m on X, LinkedIn and GitHub.

If you’re interested in this kind of content, I post it from time to time. and you can follow me there. All right, so now I’ll jump into the technical stuff and why you guys are all here and I’ll stop talking about myself. So in the beginning, us attackers, we created an attack called Credential Harvesting that consisted of us basically setting up a fake login portal of some kind.

Usually like a fake website. It might be that we had cloned a real website. So it looked just like one of the company’s real login portals. Or it might be that we had created a fake website that was just branded with the company logo that matched our ruse and it made sense to create something unique that wasn’t a clone of a real login portal.

But either way it worked the exact same. We would send a link to the fake login page to all of our target users and they would hopefully come and log in and give us their user ID and their password and that, that webpage, it would capture that data for us and then it would send them on to some other website that was supporting our ruse.

Maybe it’s a gift card, maybe it’s a survey, who knows, whatever that ruse is, we’re going to have them think that they’re actually completing while we then take those credentials and go log into their account and get access to whatever else we want to access.

back in the day before multi-factor authentication, we might use those credentials to log into their VPN, their virtual desktop infrastructure, VDI, single sign on Portal, email, SharePoint, whatever.

You could access pretty much everything with just username and password. And this was working great, this was really good. But like I said, eventually multi-factor authentication came along. And what multi-factor authentication is, probably everybody that’s watching this is familiar with it, but if you’re not, it’s combining something that we know, which is that password that we already use to log in, with something that you have.

So this was some type of token like a SMS message that you might receive. Like in that bottom screenshot on this slide where you’re getting a code through a text message on your phone and you type that into the website.

Might be a code that you get from a Google authenticator app or some other authenticator app like you see at the bottom right. Or it could be any of a number of other types of tokens. Those were a couple of the two earliest ones that we saw most frequently.

So now user ID and password alone were not, not enough for us to get into a lot of the different services and login portals that we wanted to access as attackers with that user credential that we just captured.

So we as attackers have to then, either choose to adapt or die at this point or at least that that credential harvesting attack is going to die if we’re not able to adapt somehow. So we started adapting our attacks and there were several different ways we tried to adapt and see if we could still get into accounts after the invention of multi-factor authentication.

So we started doing things like adding a fake multi-factor form to the credential harvesting page. That way if the user had to enter like a six-digit code to log in with their multi-factor Token, our credential harvesting page was now going to ask for that code.

The only shortcoming there really was that only works with something like a time-based one-time password token. So something like a Google authenticator app where it’s giving you that code that’s constantly rotating on your phone or on some other device and that code’s only usually good for like 30 seconds.

So we had to be pretty quick with how, how quickly we’re going to log in after capturing that. So that wasn’t a great solution. Another solution was to try and social engineer the target again. So get their username and password and then now that we’ve got that username and password we try and log in with it somewhere.

Now we’re going to try and social engineer them a second time to get them to complete whatever the multi-factor action is, send us a code, accept a push notification, whatever, or to do like a SIM swapping attack where we actually get that person’s phone number re registered to our own device and now we can receive the SMS message that has that code in it that they would be sent for the multi-factor authentication.

Both of these attacks are valid ways to go. But the big problem here is it requires doing two separate attacks against the same user because we have to do that initial social engineering attack where we get them to go and log into the site and get those credentials, then we got to do some other attack to get that multi-factor token.

So this increases our level of effort, increases the chances that we’re going to fail. Because you fish somebody once, yeah, you might be successful, but that second time that same person, they might be suspicious. So who knows if it’s going to work the second time.

And then another route that we tried to go was targeting gaps in multi-factor deployment where all the different services that were external to that environment might not enforce multi-factor. There might be one portal where users are asked for their multi-factor authentication and another portal.

Whether not this is actually something we still try to do today. There are tools out there that do this like MFA sweep and find me access that we use to try and find endpoints of various kinds that don’t require multi-factor in environments that do otherwise require multifactor.

But unfortunately for us as attackers those gaps are getting smaller and smaller. It’s getting less and less likely that we find a gap somewhere where multi-factor has not been deployed when it’s already been deployed elsewhere in the environment.

So ultimately what some enterprising attackers did was they came up with some new tooling for us and a new category of attack that we could do to get around the multi-factor authentication, which is an Adversary-in-the-Middle attack.

And the way this Adversary-in-the-Middle attack works is exactly how it sounds. And you can see the diagram of it there’s on the screen in this case, the diagram is showing an evil jinx server in the middle. Although this could be any Adversary-in-the-Middle tool, in the middle.

That is just evil jinx in this case because I borrowed their image off of the evil jinx blog. But that Adversary-in-the-Middle server, it sits in the middle just like it sounds like between our victim and the real login portal.

And it passes information back and forth from one to the other. So the victim visits the Adversary-in-the-Middle server. The server then goes out, makes a request to the real login portal, it gets the content on that portal, it displays that content to the victim.

The victim then submits their username and password. The process continues. That’s sent on to the real portal. The real portal sends a response back. Now the victim is prompted for their multi-factor token.

They provide that multi-factor token again, that’s sent to the real login portal. The login is completed. Our victim is then sent to some other website again that records or that supports our ruse, just like the original credential, harvesting attack.

And our Adversary-in-the-Middle server, having already captured the username and password, now captures the session token. You might think, well, why capture the session token and not capture the like multi-factor code, in the case of those one time passwords or something like that.

The reason is the session token is how every web application that you log into works. And so this becomes a universal way for us to get in that the session token is something along the lines of a cookie.

Usually it’s a cookie or some other thing that gets saved in the browser. It could be like a header that’s sent by the browser or there’s other ways this is implemented sometimes, but usually it’s a cookie that’s saved by the browser and it’s sent in every, every request that the browser makes to the web application after that user initially logs in.

And the reason for this is because HTTP is in and of itself a stateless protocol. So there’s not any way for the application to know that the person that just now submitted that username and password, that the next request that comes from their browser is coming from the same person without doing something, something else in there to figure it out.

So that username and passwords, submitted. The application then sends back this session token. The browser holds onto that session token and it sends it in every request from then on. And every time the application sees that token it knows, okay, this is that user that signed in before, so I should give them access to their account.

But what we as attackers can do is we can capture that same session token, we can put it into our browser and we can send it and every request that we make to the same service. And now we’ve just jumped straight into that session that the other person logged into.

We’ve done an attack called session hijacking where we don’t even need the username and password at this point and we certainly don’t need the multi-factor token. And that’s the main thing we’re trying to get around here because we did capture the username and password and we’re able to access everything that user would normally be able to access.

And there’s a lot of other ways to be able to do this same session hijacking attack too. This is kind of like a broad category of attack. You could, you could say, that a lot of other attacks feed into. So this is an attack that Adversary-in-the-Middle ultimately results in, but that you could also get to this point from other types of attacks too.

So that’s a bit of an introduction to session hijacking to explain why we’re doing it this way. And there are different approaches that different Adversary-in-the-Middle tools take to make this happen. So I’ll tell you a little bit about the different types of Adversary-in-the-Middle tools that we’ve got.

So the first is probably the one that you’re most familiar with. It’s the proxy based Adversary-in-the-Middle tool, where our tool acts as a reverse web proxy between our victim user and the real login portal.

So exactly like I was saying before, we’ve got a server like Evil Jinx or Modlishka that’s sitting out on the Internet and our victim, they’re using their computer, their mobile phone, whatever, to make a web request to our server.

Our server then sends its own web request out to the real login portal. It gets back HTML data, whatever other web data back from that login portal, sends it to the victim. And this goes back and forth just like that.

So what’s being presented to the, the victim in this case to their device is a real website. It’s actually the real login portal with Maybe a few small changes made in between to make the whole proxying process work.

But it’s that same HTML data. There’s a second type of Adversary-in-the-Middle which is instead browser based instead of proxy based. So this is also referred to as browser in the middle.

And this is a situation where the victim is actually logging into their real login portal through the attacker’s web browser. So the really like low tech way, you might think of this, that would be an unsophisticated equivalent, would be if you sent someone a link to access your computer to have like a remote desktop session on your computer and you opened up your web browser on your computer to show something they’re going to log into and they log in through that session.

They just logged into their login portal through your web browser. And this is effectively what these other tools like Cuttlefish and Evil Novnc do is they set up a remote session in the victim’s browser.

So that still looks like the victim is viewing a web page, but what they’re actually seeing is the webpage as it is shown through the victim’s or through the attacker’s browser. And when they log in, they’re logging the attacker’s browser into that web page.

And whenever they get logged in then we as the attacker again we send them on to some other website so we can then run amok in their account however we like. Then there’s the third type of Adversary-in-the-Middle and that is human driven tooling.

Or these days it also might be AI agent driven tooling. But this is a situation where we have a credential harvesting page set up just like the traditional credential harvesting page.

So this could be a clone of a real login portal. It could be something we’ve made that’s completely unique and just branded to look like whatever it is we want them to log into. But they log into it. That credential harvesting page captures their username and password.

And then what happens is the attacker is actually sitting and monitoring this in real time and they take those credentials that were just submitted and they turn around and they go use those credentials to try and log into the company’s real login portal.

When they do that, the company’s real login portal prompts them for a multi-factor token of some kind, push notification, enter a six digit code, whatever. They then interact with that credential harvesting page with a feature that you would consider like, analogous to like a web based chat type feature.

Like you Might see to interact with customer service on many websites that are out there today. But instead of sending a message to the user that shows up on the website, they send a fake multi-factor prompt that asks for whatever the real login portal had just asked the attacker for.

Could be a push notification, could be again a code, whatever. Then the victim does that action on their end and the, the attacker is then allowed into that website. If they, if the victim entered a six digit code, the attacker enters the same code.

If the victim accepted a push notification, the attacker is already in. At this point I don’t have any examples of tooling for this because the only examples that I know of it are tooling that’s used by either like pen testing companies that are private and haven’t released it to the public or that are used by real world attackers.

So there’s not any public tools that I’m aware of out there that do this. But to be honest, this is not really my favorite approach. Even though it’s pretty sophisticated and effective. But it requires somebody sitting at the keyboard 247 to be able to interact with a victim.

So it’s a lot of work for whoever’s doing it. So we start thinking about all these tools and thinking about the way this attack is done. And one thing I want to ask myself right away is well, what do all these tools have in common?

What is it that makes Adversary-in-the-Middle work no matter what tool is being used? And the number one thing that all of these tools and attacks have in common is that the login is always coming from the attacker’s computer every single time.

Whether it’s the reverse proxy method where we’ve got evil Jinx or Modlishka out there on the Internet and it’s being a reverse web proxy. When that username and password is submitted to the real login portal, it’s submitted to that portal from the eviljinx server or the Modlishka server.

When it’s browser in the middle, there’s some server sitting on the Internet that’s running our browser, our attacker browser. And when the victim makes their login, request through that browser, the login request is coming from that browser. So it’s still coming from the attacker’s computer.

Whenever it’s the manual Adversary-in-the-Middle tool. Well in this case the victim is submitting their credentials to the credential harvesting page and then the attacker is reading them and then from their own workstation actually submitting the credentials so again the credentials are being submitted, the login is being done from the attacker’s own computer.

And this gives us an opportunity to try and find a weakness for Adversary-in-the-Middle to try and find its kryptonite. All we have to do right is identify when the login comes from the attacker’s computer.

So how do we do that? How do we find the attacker’s computer whenever they’re doing one of these attacks? Well one of the things we might try to do is we might try and identify any suspicious IP addresses that are used to log into a user’s account.

maybe an IP address that’s on the Tor network, maybe it’s coming from a VPN network. Maybe it’s an IP address associated with some cloud service like DigitalOcean or something like that. Well that’s something that’ll work part of the time, but it won’t work all the time.

It won’t work for sophisticated attackers that actually know what they’re doing because it doesn’t work if our attacker gets a business, residential or mobile IP address that’s not part of the Tor network or associated with some kind of vpn.

And there are actually legitimate businesses out there that sell access to business, residential and mobile IP addresses. And we as attackers can just go subscribe to one of those services and send our traffic through that. Now we’ve got a legitimate IP address in a region that makes sense and and we can get around the detection of a suspicious IP address.

So that’s not going to work against most of the real attackers that are operating out there today. Same thing for suspicious devices or browsers. So what if we said like, what if it’s a device that the user doesn’t normally log in from or a browser they don’t normally log in from?

Like what if it looks like they’re logging in from Kali Linux or something like that? Well actually again this is not going to be the case for most Adversary-in-the-Middle attacks. Most of the Adversary-in-the-Middle, tools that are out there automatically mimic the victim’s device and browser.

So that, that’s not going to happen as a detection as long as the attacker knows what they’re doing. if again it’s going to detect the low hanging fruit, the attackers that just downloaded this thing from GitHub and are using it for the first time, but those attackers that actually know what they’re doing, it’s not going to stop them at all.

So now we’re kind of in a bind here, like how are we going to figure out, what, what logins are coming from that attacker’s computer? Well we could take the opposite approach. We could try and identify when a login does not come from the attacker’s computer.

And one thing we know about the attacker’s computer is that the attacker’s computer is always not the computer that the victim is physically using. That in every one of these attacks that computer is somewhere else in the world and it’s not the computer that the victim is actually logging in from.

And if you start thinking back to like what I initially said about multi, factor authentication, how it’s something we know and something we have, shouldn’t we already know which computer is the computer that the real user is logging in from?

Because something you have, that whole concept of something you have, implies that there is close proximity between our user and the computer that they’re logging into and the thing that they have in their hand, assuming, that they actually have a token in their hand.

And when you start thinking about this, you realize that multi-factor authentication is not actually what it has been described to be. It is not actually something plus something you have.

Actually it’s something totally different. So in practice these different multi-factor tokens that I’ve got listed here on this slide are different things. one time passwords or time based one time passwords. So the codes that you get from a text message code that you receive in an email, code that you get from something like Google Authenticator, those are all something they’re not something that you have.

So that’s, you could easily tell someone else that code and that would be something that they know. Now it’s something that someone knows, it’s not something that you actually physically have in your hand. Same thing for push notifications. If you get a push notification that you’ve got to accept on your device to log in, the push notification is not something you have.

It’s actually something that the person who has the token device will do. And you can, you can illustrate this pretty easily, by say for example, if you were to go into the office one day and you accidentally left your phone at home, but you had a family member who was at home and they knew the PIN to your phone, you could call them up from your office phone because you don’t have your mobile phone with you and you could ask them to unlock your phone and accept a push notification for you because you’re trying to log into your work computer and you can’t get logged in.

And they could do that because it’s not something you have, it’s something that someone who has access to the token will do. And the same thing is even true with the push notification plus the two digit code that Microsoft likes to do.

With the Microsoft Authenticator app, where you see a two digit code on screen, you get a push notification, you’ve got to enter two digits and then accept that’s a combination of the last two. It’s something that the person with the multi-factor device will do and it’s something, neither one of those is something that you actually have.

So now we’re in a situation where we need to figure out a way to actually make multi-factor work the way that it is supposed to work and actually prove that there’s something that we have. So what multi-factor really needs to be is something, plus something we can prove that you have.

And the way we can prove that, that you actually have something. At least one way we can prove it is that there’s a device in the user’s possession. We start with that and then step two, that device completes an action that nothing and no one else can do.

And the way it does an action that no one and nothing else can do is that it has access to data that it’s using to complete that action that nothing and no one else has access to. And the way we can do this is, is with public key cryptography.

I won’t get into a deep dive on what public key cryptography is right now. So if you’re not familiar with that term, you may want to look it up after. But the main thing to know about public key cryptography is that in public key cryptography we have two keys for whatever data we want to encrypt or sign or anything like that.

We have a public key and a private key. Your public key, it’s safe to share with everyone in the world. That is the key that’s used to say, encrypt messages that are sent to you or to sign messages that are sent to you.

The private key is used to decrypt the messages that are sent to you or to verify, the signature of the public key. And the opposite can be done too. So data can be encrypted with the private key that would be decrypted with the public key.

And it can also be signed with the private key. and, the signature can be verified with the public key. That’s all you really need to know about how that works. Although like I said, if you’re, if you’re interested in getting deeper into it, definitely look it up.

So one method of multi-factor authentication that is available to us that leverages public key cryptography in this way is a Fido 2 passkey, or just passkey for short. And there is a two step process for how it works.

So in the first step we got to set it up to use it with our account. So in this step the token device that we’re using, and this can be a phone or it can be a hardware token like a Yubikey. there’s several different things that can fill this role of a token device.

But that token device generates and securely stores a public key and a private key pair that are going to be used for this whole process. And when I say securely stores, usually that private key is then stored on like the trusted platform module or the devices equivalent of that.

it could be the secure enclave in case of Apple devices, Titanon Google Pixel, other terminology on other types of devices. But basically it’s a hardware module where things can be stored securely and cryptographic operations can be done on them, but that the general operating system of the device cannot access that data.

So it can’t be stolen easily by an attacker. So once that key pair is generated on the device, the next step is the client software. Usually the browser reads the public key because that data is accessible.

It’s just the private key that’s not accessible from the token device and it reads it over a local channel. This is really key here is that data is read over something like Bluetooth, nfc, near field communication, usb, or it’s built into the local hardware itself and it reads that data and then it sends that public key off to the portal that the user is going to log into.

This is the registration process for their account where they’re registering this a passkey with their account. And once this is done, it looks like that screenshot that you see down there at the bottom where I registered my passkey with Microsoft 365.

So now that public key is stored with the user’s account just like say their password hash is stored with their account. Once that’s done, now the user can use this pass key to log into their account.

So step two is anytime the user starts a login request to this service, the portal sends a challenge to that user’s client, their browser. The browser then starts communication with the token locally over one of Those local channels.

And the user has to unlock their token using either a pin or biometrics or something like that. Once the token’s unlocked, the token now can send the. Well it actually receives.

Rather sorry, it receives the challenge data from the browser which was sent by the portal. And all the challenges is it’s just some unique data that’s not easily guessable or anything like that. It’s just something unique to that response, that one login process.

So that challenge is sent to the token by the browser. The token signs the challenge data with the private key that it generated before and then it sends back the challenge data to the browser, including that signature.

The browser sends the signed challenge data back to the login portal, and the login portal now looks at the challenge data it received and the challenge data it sent, makes sure they’re both the same data. So we haven’t been the victim of any kind of interference or anything like that.

And the signature on the challenge data that it received, it checks and makes sure that is a valid signature for the key that it has the public key for. So it’s able to use that public key to verify the signature.

As long as the signature is valid, then that is definitely the user on the other end that is meant to be logging in here. It’s cryptographically secure and proven that the user has access to the private key that the portal has access to the public key for.

So that is how the whole passkey process works. And now we have a, process that actually is something we know and something we can prove that the user has. Especially because all this was done using again local channels to access that passkey.

So at this point, hopefully what you’re wondering is you’re wondering how do I know if my multi-factor on my account is secure or not? Am I using a passkey? Am I using some other method that’s secure against Adversary-in-the-Middle, or am I using one of the insecure multi-factormethods?

There are a lot of different options out there for multi-factor tokens, some of which I’ve got listed on the screen. Some of them seem complicated and seem secure. For example, passwordless is one that I’ve heard repeated, or mentioned repeatedly that people assume is going to be secure because there’s not a password anymore.

The attacker can’t get your password. The, user doesn’t have to remember a bunch of different passwords. that’s got to be more secure than what we’re used to, other Things like there’s multifactor third party services and apps that are add ons for services that seem secure.

Even that push notification. Plus the code that I mentioned earlier that seems like it’s more complicated right, because you’re going to get a notification on your phone then you got to put in this code. It seems complex. How do we tell if it’s actually secure or not?

There’s a really really simple test we can do and it leverages what I told you about Adversary-in-the-Middle tools that always the attack is coming from a login on a computer that is not the computer where the user is sitting.

So therefore if someone can log into your account on a physically remote computer with your help, like obviously if they could do it without your help that would be a problem. But even if they can do it with your help, then your multi-factor is vulnerable to Adversary-in-the-Middle.

So hopefully that makes sense. Just in case it doesn’t, I’m going to demo it for you and we’ll see it in action. So I’m going to have Joseph Kingstone jump on the call. Joseph, if you’re still out there. There he is. And I’m going to let Joseph log into my own Microsoft 365 account with a little bit of help just like as though I was getting hacked through an Adversary-in-the-Middle attack.

And we’ll see which tokens he is able to exploit to get into my account and which ones he is not. So Joseph, if you want to go ahead and share your browser, or if you’re already sharing it, maybe we need to get his browser up on screen and we’ll kick this thing off and try out some of these different tokens.

All right, cool. There is the Outlook browser on Joseph’s computer. Joseph, go ahead and sign in with my account. I’ve gone ahead and shared my user ID and my password with him because I didn’t want to say the password on the webcast because when I share my multi-factor token in just a minute anybody else who’s watching would be able to log into my account if my multi-factor token is weak.

So Joseph already knows my password so go ahead and get started there and we will start with an SMS text message to kick this thing off and see if he can log into my account with an SMS text message and he’s going to get a couple of prompts because I have set up literally every token type that I was able to set up on this account.

So we could test a bunch of them.

Joseph Kingstone

All right, Ryder, you ready for the text?

Michael Allen

Yeah, yeah, send me that text.

Joseph Kingstone

Fantastic. here we go.

Michael Allen

Okay, text message just came through. The verification code is 699712. And, sure enough, he’s in my account. And as I expected that everybody on the webcast would think, this is by far the least secure one.

So this is the one we started with because it’s like, yeah, obviously the SMS is going to be insecure. So let’s try a different one next. Let’s do the time based one time password, which is going to be the authenticator app, code.

The authenticator app code will be the next one. So I’ll let Joseph get logged out of my account and try and log back in and I will get my authenticator app pulled up on my phone.

Joseph Kingstone

All right, Getting re logged in here. All right. Other ways to sign in. All right. Approve a request on my Microsoft authenticator app.

Not. Not that one. The. Or did you already do this? I can do that one too.

Joseph Kingstone

I already screwed up the. Already, screwed up the demo. Rhino. Here we go. Perfectly fine.

Michael Allen

That is what we expected was I expected this to not work out perfectly, since we only practice it the one time.

Joseph Kingstone

Okay. Okay. Verification code.

Michael Allen

Yes, that’s it.

Joseph Kingstone

All right, fantastic.

Michael Allen

Okay, and verification code is 200268.

Joseph Kingstone

All right, here we go.

Michael Allen

Boom, there it is. Okay, so the time based one time password also terribly insecure. so let’s have you log out again and this time let’s do the phone call. So this one was one that during our test, of the demo yesterday, I was actually really amused by this one because I was expecting it to be at least equal security to the last two.

And this actually turned out to be like the least secure of all. I’m going to put this on speakerphone whenever the call comes through and hopefully everybody will be able to hear it.

Joseph Kingstone

Okay, let me know when you’re ready and I’ll go ahead and.

Michael Allen

I’m ready.

Joseph Kingstone

All right, fantastic. Here we go.

Michael Allen

Waiting for the call to come in. Okay, I, see the call coming in. I’m gonna answer the call. I’m gonna try and put it on speakerphone. If you are trying to sign in, press the pound key to finish signing in. Okay, so it just said press the pound key to sign in.

So I’m press the pound key. That’s it. It’s just press the pound key. Like I didn’t even have to get a code. I thought it was gonna call and tell me a six digit code that I’m gonna have to tell Joseph. It’s just calling and telling me I could text somebody and tell them, please press the pound key when you get this call.

And then they get me into their account. So I was amazed at how terrible that one was. we’ll have you log out again and now we’ll do the Microsoft authenticator. So Microsoft authenticator is going to be the push notification to my phone plus a text code that I have to put in.

So this, this seems secure to, lots of people whenever they do this. and it seems like it’d be more secure than regular time based one time password or SMS message like we did before.

But we’ll see if it’s actually any more secure or not.

Joseph Kingstone

All right, pushing it now.

Michael Allen

All right. Okay. Approve sign in request. I see the 98 on the screen. That screen could just as easily be a man in the middle, like Adversary-in-the-Middle tool. So I’m typing in 98, I press yes on my phone and let’s see what happens.

There it is, approved. And he’s able to get right into my account.

Joseph Kingstone

Logged in.

Michael Allen

All right, so all of the authentication methods we’ve done so far are with a password. So I want to do one more with a password before we start testing out passwordless. So go ahead and do it one more time, Joseph.

And this one we’re going to do the ub key for the multi-factor method whenever you get to it.

Joseph Kingstone

All right.

Michael Allen

And I won’t take over the screen share from you yet whenever we test it because we’ll test a couple more password lists before I take over the screen share.

Joseph Kingstone

Sure. All right. yep, security key coming in now.

Michael Allen

All right. Okay, so I see the prompt on your computer that says insert your key into the enter the port. Can you pull that back up again? Can you have it do it with the key again?

Joseph Kingstone

Yep, gotcha.

Michael Allen

Because when you’ve got that up, I’m going to press the button on my UB key and we’ll see if it signs you in.

Joseph Kingstone

All right, here we go.

Michael Allen

Okay, perfect. So insert your key into the USB port. Done. Pressing the button on the Yubikey. And what’s happening right now on my computer, nobody can see this, but you’ll see it in a minute. Whenever we do switch is, I’m just getting a bunch of random text coming up in my notepad window that I’ve got opened up because I wanted it to type into something other than this, webcast, but it’s not interacting with Joseph’s computer, so it is not completing the authentication.

So if this was to happen during the middle of an Adversary-in-the-Middle attack, the attacker would not be able to capture this token even if they captured this random text. As you’ll see in a minute, there would be nothing for Joseph to do with that random text which when it comes across the other end.

Because this text that happens when I tap on the Yubikey, it’s not actually the private key or assigned challenge response or anything like that that’s useful in this authentication scenario. So go ahead and cancel that Joseph, since you can’t log in.

And let’s do passwordless authentication now. So let’s try passwordless authentication with the Microsoft Authenticator app. Yep, there you go. All right, all right.

So now he did not enter a password for me. I’m being shown a two digit code on the screen. I’m going to, let’s see if everybody can see this code. I just typed it in. So I just typed in the 2, 2 digit code. Where am I?

I don’t know if everybody can see this. My, I’m getting a bit of lag on my camera. So there we go. so I typed in a two digit code and now I am pressing yes. And if we can go back to Joseph’s browser, you should be signed in any moment.

Hopefully everybody is seeing the browser because I see Joseph for some reason I don’t know what I’m doing. Okay, so that worked. That’s passwordless. So that did not require any, you having access to my password.

You could have just called me up or texted me and said, here’s a two digit code. Enter this two digit code on your Microsoft Authenticator app and you would have been granted access to my account. That’s technically, in my opinion, that’s less secure than if we actually had a password.

And then an Adversary-in-the-Middle tool could just as easily do the real same exact thing. So now let’s try one more, let’s try passwordless, but let’s do it with the passkey this time.

Joseph Kingstone

let me re delete these cookies here. All right, Ready?

Michael Allen

Yep. Ready.

Joseph Kingstone

All right.

Michael Allen

Okay, once again I’m getting the prompt to insert my UB key. So I’ll do that. I’m m pressing the button on the Yubikey and once again a bunch of just gibberish shows up on my screen and absolutely nothing happens on Joseph’s screen.

So once again Our Adversary-in-the-Middle attack would be foiled by using a passkey of some kind, whether it’s a Yubikey, whether it’s a smartphone with a passkey, whatever it is. So what I’m going to do now is I’ll switch to sharing my browser and I’ll show you one more authentication here.

I’ll show you what it looks like when the passkey authentication actually works. Thank you for all that help, Joseph. That was a huge help being my login guy for the demo.

Joseph Kingstone

I have your real password too, Rhino, just so

Michael Allen

You have my real password too?

Joseph Kingstone

Yeah, yeah, Bhis. Okay. Crap.

Michael Allen

I don’t know how that happened, but, hopefully it was amusing. I try and make all of my passwords really as funny as I possibly can so that they’re amusing to anyone that gets them. All right, so here I am logging in on my own browser, this time logging into that same account.

And I’ll do other ways to sign in. I’m going to do the password list with the, face, fingerprint, pin or security key. So this is the option to do password list, sign in. I could also sign in with password. I’ve got both set up.

but just for time, I’ll just do passwordless. and it looks like the prompt on my computer is actually not showing up for everybody out there. So you’re seeing what the browser is showing on my computer is prompting me for, either my Yubikey or my smartphone.

because I can do this over Bluetooth as well. So I’ll actually do it with the smartphone for this one and we’ll see if it shows anything different than before browser. So what I’ve got to do with the smartphone and I’ll see if I can share this window. So everyone is seeing this and it’s pretty, it’s pretty interesting if I am able to share it.

I don’t know if it’s. It’s not the kind of window I can share. I don’t even see it in the list of windows that are available through Zoom. But it’s giving me a QR code to scan with my device. And if I scan this QR code, it’s, it’s going to initiate the passkey authentication.

But I’m trying to find my camera on this iPad that I’m using here for the demo. But it is not, useful to anybody else. So if I was able to show this QR code, which unfortunately Zoom won’t let me show, then, you could all still scan the Qr code if you wanted and it would be worthless to you.

It would actually not allow you to authenticate to my account either because it’s just telling my computer, how to talk to my device. So it says device connected. I tap, continue on my device and scan my fingerprint to unlock the token.

And it took me too long I think. So it says something went wrong. We’ll try it again. This time I’ll do the security key just to keep things simple. So I’ll do a security key, I type in a PIN to unlock the security key and then I press the button on the security key and then sure enough I’m now signed into the account.

So just I guess this is the demonstrating that the passkey actually works and wasn’t just set up and not working as for the demo. So it actually works. I am actually able to log into the account.

It looks like it’s taking a minute to load up my screen because I’m getting a bit of lag. All right, so there is access to my email. I’ll jump back to the slides and I’ll finish up the last couple of minutes of the presentation here.

As soon as I find this slide window, there it is. All right, back in the slides and onto the results. So so here are the results of our test. we tested the phone notification which was by far the worst because it was just, it was literally answer the phone and press a button and we’re logged into your account.

We tested one time passwords, be they over SMS or you can also get those over a phone call in some services. I was expecting a phone call here but we didn’t get that on the phone call. We got a notification on the phone call instead.

Just a one button press that’s also insecure. The time based one time password, equally insecure, push notification plus the code, equally insecure and passwordless. Plus the push notification with code was also pretty darn terrible.

Like we didn’t even have to have the password and we could have easily phished somebody and got access to their account that way. The only things that stood up to Adversary-in-the-Middle in this demo were the FIDO to pass keys. We could use our fido to pass key with a password or without a password.

And that passkey could be the Yubikey hardware token. It could be on a smartphone. So it can be a smartphone that your users already own. in some cases with some services you can even do a passkey on your computer stored in the TPM on the computer.

I didn’t demo that one. But that is an option for some services, not for all. So the next steps here are. Well okay, so we’ve figured out how to identify the multi-factor authentication that’s weak.

How do we identify it in our environment and fix the weak multi-factor that’s in our environment. So what you want to do is I’ve put check marks next to the number one and two here. Cause that’s what I showed you how to do is identify the weak multi-factor tokens and the secure multi-factor tokens that your organization allows.

So go into your account for your organization, create every type of multi-factor token that it’ll allow you to create and test them one by one and see like is this one secure, is this one not secure? Some of them are going to be obviously insecure.

You don’t even have to test them. I’ve already told you, the one time password, the time based one time password, the ones purely notification based, all those you don’t really have to test, you can assume that they’re weak. But if you want to test them, you now know how to test them.

And if there aren’t any that are secure that are available to you while you’re going through this testing process. If you’re an administrator, please enable the secure ones for your organization. If you’re not an administrator please contact an administrator and have them enable them for you.

I found out while setting up the demo that, that Microsoft 365 the default configuration has the passkey option disabled as I got in the screenshot down here at the bottom right.

I don’t know why this is, this is ridiculous to me. Like time and time again I see Microsoft services and applications have the insecure options configured by default and you have to do extra effort to go in and turn on the more secure option.

And that’s, that’s terrible. It should actually start more secure at the beginning and then if someone wants to turn off the extra security because they have a reason to, then they should be able to go in and turn off the extra security. So yeah, I don’t know why but Microsoft default configurations are bad and Microsoft should feel bad about that.

We abuse their default configurations all the time from email spoofing use over direct send. We got a blog post about that Steve wrote to teams phishing to everything else. So calling you out here, Microsoft do better.

so find those weak and secure multi-factor methods that are allowed by your organization. Then step three is enroll all the users in the secure methods, get everybody set up with a passkey or whatever the other secure method is that you offer.

And then finally disable and disallow. That’s really key to disallow the weak MFA methods so that someone can’t go in and manually add it back to their account. You’ll have everybody in your organization set up with strong secure MFA that’s resistant to Adversary-in-the-Middle.

If that’s too expensive, if that takes too much time, money or other resources that you can’t spare at the moment, there are small steps you can take to get there. So one thing you can do is you can start by implementing the stronger MFA methods on the high risk accounts first.

So start with your administrators, like your global admins, your domain admins, people like that, your executives, your developers. Basically anybody that’s got one access to everything in the organization, that’s your administrators, access to financial stuff like the ability to send the company’s money out somewhere.

That’s like your executives, your accounting people, access to intellectual property. Anything that someone has direct access to and is highly valuable. You want to lock those ones down first. And there are a couple of other alternatives to this.

They’ll also call out if you need to keep on using those weaker methods of multi-factor. other alternative is to, in addition to using the weaker multifactor, so called multi-factor. That’s why I’ve gotten quotes, is to disallow web login from all external IP addresses.

So that would mean people can only log in from the company network when they’re on site, in the office or from the vpn. So that would prevent this attack from working because again the login always happens from the attacker’s computer.

So if the attacker can no longer log in from their computer, neither can we. That solves this problem. You can also disallow logins from unauthorized devices by enforcing certificate based authentication on the device.

So it’s going to use similar public key cryptography to authorize and verify that the device is a device that is actually authorized for the environment before a user is allowed to log in.

Those are two alternatives that would, you still need to pair with the, traditional mfa. but my, my biggest recommendation would be to use the stronger MFA and roll that out to your organization if at all possible.

So with that, that is the, that’s the end of this little talk. thank you all for listening again. I got links to my classes there if you’re interested in learning more about this or also, links to my social media and I will stick around and answer a few questions if anybody’s got any questions that I can answer related to this.

Daniel Lowrie

Oh, Michael, Michael, Michael. There are many sundry questions. I am looking at the zoom questions and there were plenty of them that came in trying to find them. Now they’ve disappeared on me. Where’d you go? Zoom questions.

But there was one specifically that was asking about. Of course you’re getting through. The, the target that you’re working with is giving you everything you need to get through. And so like, I’m guessing they’re giving you their MFA token and things of that nature.

I’m, I’m assuming that’s what they’re referring to. How common is that? That that would be a part of the attack, that the target would actually be giving the attacker information that allowed them to gain access to the system?

Michael Allen

Yeah, so let me to give a little bit of extra clarification there. That is exactly what happens in every Adversary-in-the-Middle attack. That is exactly what happens. I didn’t give Joseph any information that he would not get if he was using Evil Jinx, Modlishka, Cuttlefish, Evil Novianc, any of those other tools that I showed because I was seeing his screen on the webcast.

And in every one of those cases the victim would be seeing the screen of the tool logging into their account and acting as the attacker. So that is, it was 100%, real.

And the way that it actually happens in a real world attack with those tools.

Daniel Lowrie

And that’s a great answer. So thank you for clarifying that because it was just. It does seem to be almost incredible that that would occur, that people actually would tell you the thing that is supposed to keep them secure.

But it does happen quite often.

Michael Allen

Hello.

Daniel Lowrie

Social engineering is a very useful and valuable technique for gaining access to a lot of these things. And that does kind of bring us to the idea because there was a lot of questions as well about MFA fatigue. How much or how effective is MFA fatigue for giving you the access you’re looking for?

Michael Allen

It’s extremely effective. That is why I called out the, phone call where you can just press the pound key as letting you into the account as being terrible. The push notifications, where you just accept the push notification and that’s all you do are equally terrible because all an attacker has to do is send the push notification over and over and over.

And the regular user, that’s not technically sophisticated is going to be like why do I keep getting this notification? Is something broken? They’re going to decline the first few times but they’re going to want to want that notification to stop. They’re going to say okay, well let me just accept to get it to go away.

And now the attacker’s in the account.

Daniel Lowrie

Oh man, it is hard. There’s a lot of conversation that you have drummed up. Good sir, awesome to find. let’s see here. It says if you have access to vdi, is it a good way to see firsthand how a Fido key interacts with the physical computer, not the VDI session?

Daniel Lowrie

Also they get it’s not a question, but it kind of is.

Michael Allen

Yeah. So I think what they’re getting at here is basically could the same method of testing your MFA be done over a remote access session rather than having like your own Joseph somewhere off site to do it for you?

And yes, that’s actually an excellent way to do it. what I would say you need to do is make sure it’s a computer that’s outside of your organization’s internal network because they might have conditional access policies that are going to skew your results of your test.

So like if you’re in the office, you’re making a VNC or remote desktop connection or something like that to your home computer and you’re trying to log in from that home computer using your token that you’ve got in hand in the office. That would be kind of an ideal situation because you want it to be a computer that’s outside your network that you’re remoting into with something like vdi.

you could potentially share your local USB port with a VDI host and that would actually negate the test. But because then you’re actually sharing that key with the host and the host is going to have it.

but that’s not the way that Adversary-in-the-Middle tools work. They don’t actually take over the ports and it’s because they work through the browser that they’re not able to do that. So like a TeamViewer or again RDP, VNC, something like that to your home computer.

That’s going to be a much more telling test.

Daniel Lowrie

Someone was also asking about obviously we’re using Microsoft for this demonstration but what about Google? Are they less or more or as equally strong?

So the exact same multi-factor methods will be vulnerable regardless of what services. So it doesn’t matter if it’s Google Duo. Okta? any other multifactor provider out there the time based one time password will be equally weak.

SMS messages equally weak. Phone calls might be slightly different. They might not be press a pound key, it might be get a code but it’s still going to be vulnerable to Adversary-in-the-Middle. All those same methods are going to be vulnerable to the Adversary-in-the-Middle regardless of who the provider is.

I just picked on Microsoft in this one for two reasons. One, Microsoft is 95% of the customers that we see are using Microsoft. So I wanted to use it for that reason because the remediation is going to be applying to more of our audience probably.

And two, it was the easiest for me to set up all of those tokens on with a enterprise similar account. I could go out, I could create a tenant and I could create I could set up all the tokens like very easily. So yeah, for user friendliness I gotta say Microsoft’s doing a good job of user friendliness.

It’s just the security they’re kind of lack not doing so good at awesome.

Daniel Lowrie

David asks so is the proper way to implement this in a cloud environment to set up. I love that thing. Loves to jump out of my way. to set, set up Yubikeys for external MFA along with a conditional access policy that allows push or other MFA from the cloud environment.

Michael Allen

Let’s see. So for the cloud environment setting up.

Daniel Lowrie

UB keys for external MFA along with conditional is, Is that what you do? Do you set up an external MFA along with conditional access policy that allows push or other MFA from the cloud environment?

Michael Allen

Yeah, what I’m thinking about is like I’m trying to make sure that they’re not asking about a situation that I’m not thinking of. Maybe if there’s some kind of strange situation that would involve the cloud environment. If we’re talking about say cloud desktop like a VDI or something like that?

yeah. Really? The. Well yeah, it depends on whether the user can share their USB port with that VDI or not. If they can share their USB port then the UB key is going to be just fine to lock that down.

If the user cannot share their USB port then yeah, accessing the cloud environment say over a VPN and then using the conditional access policy to lock it down to the VPN IP address or using conditional access policy to only allow login from authorized devices that are using something like the certificate based authentication in addition to your traditional mfa.

Daniel Lowrie

Gotcha. Here’s a. Here’s an interesting question. Are there API safeguards that would help with some of the less secure MFA methods or am m I confusing apples and grapefruit?

Michael Allen

Let’s see, as far as the API methods, I mean it’s not an implementation of the MFA that’s the problem. It’s that the real problem is the weaker MFA methods are not verifying.

It’s actually something that you have. They are verifying. It’s something that or it’s something that you can do or that someone else can do. So even by, trying to have robust API calls and things like that or security around the API, it’s still not going to solve that problem.

As long as it’s. As long as it can be logged in with something other than what a person actually physically has in their possession, it’s not going to be true. Multi factor.

Daniel Lowrie

I did see some people asking a bit about, obviously I think we’re using Yubikey as your primary. This is a 502 key. Any other alternatives for that that you would recommend?

Michael Allen

There’s not any that I can recommend just because I would only recommend things that I’ve actually tested myself. I know there are other alternatives out there. There are some open source alternatives and things like that. the possible problem with some of those open source alternatives like build your own hardware token is that the private key may or may not get stored on a trusted platform module or equivalent the secure module on that hardware.

So something else might be able to read it. So it wouldn’t be equivalent to Yubikey for that reason. But at the same time the odds that something is going to hack your teensy or whatever you set up to do that is pretty low.

I mean that’s like really specific. So it’s still going to be better than the traditional mfa. It’s still going to be secure against Adversary-in-the-Middle. And that’s like the threat that we’re trying to target with this content here at the moment.

Daniel Lowrie

Well Michael, this has been a very thought provoking conversation. Obviously. I mean, chat’s going berserk. Lots of Q and A. We could probably spend half a day just having this conversation with the good folks that joined us today answering questions and stuff.

But I know your time is precious and look at that, it is 2:00 and it’s the end here. Oh, you nailed it. It was chef’s kiss. Good job everyone. This has been how to test Adversary-in-the-Middle without hacking tools with Michael Allen.

We thank him so much for his time and we thank you for joining us today. Be on the lookout for more BHIS webcasts in the future. And don’t forget, we’ve got the Red Team summit coming up very, very shortly. So definitely run over to Antisyphon Training and Black Hills Information Security to check out all the cool things that we have in store for you that are coming up very shortly.

That said, we’re going to call it a day. And Megan, you can kill it with fire.

---

---

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

---

---