Hello and welcome to the let's Talk. Azure podcast with your host Sam Foote and Aaron Armstrong. If you're new here, we're a pair of Azure and Microsoft 365 focused it security professionals.
It's episode 34 of season five. Sam and I had a recent discussion around token theft and token replay attacks. These attack methods are becoming more popular and organizations are needing to put in security controls to reduce their risk of attacks. Here are a few things we what are authentication tokens? What is token theft and token replay attacks? How can an organization reduce their risk of tokens being stolen? And what measures can an organization put in place to prevent token replay?
We've noticed that a large number of you aren't subscribed. If you do enjoy a podcast, please do consider subscribing. It would mean a lot to us for you to show your support to the show. It's a really great episode, so let's dive in. Hey Alan, how are you this week? Hey Sam, not doing too bad. How are you? Yeah, really good, thank you. It's that time of year again, Alan. Is it?
It's the time of the year where Apple released a new iPhone and there's a string of replies saying, and the top comment on Tim Cook's announcement about it going, that was in Android ten years ago. I wasn't expecting that to be fair. I expect you to say something around ignite again and that, you know, it's sold out. Sorry. Yeah, sorry, apologies. Keep it on brand. Yeah, yeah, ignite. Yeah, it seems like it's pretty popular. Sold out now, which is sold out.
In three days, I think, or something like that. Yeah. The technical and then the partner ones now sold out, I think. Yeah, more expensive extra day. Yeah. So really good. So hopefully, hopefully that's just really good demand. Not, you know, a limit of size if that makes sense, you know, but yeah, really interesting to see. Be really interested to see, you know.
How that, yeah, I think the location change was really to increase the capacity of it. And then as you said, they now do an extra day as well. Kind of back to what it used to be from a, like a Tuesday to Tuesday to Thursday. Well, Tuesday to Friday. There's some stuff on Friday as well, but mainly Tuesday to Thursday with a pre day on Monday. So yeah, like you said, increased cost probably because of venue and an extra day. But actually I guess technical teams, organizations are seeing more value because it's more of a week event pretty much now. So. Yeah, yeah.
Because if you have the travel, you know, in some respects it's the travel time, which eats up the cost and obviously the time as well, you know. So yeah, having an extra day does make it worth, worth of travel, doesn't it? In some respects, yeah, definitely. Cool. What we're talking about this week.
Yeah. So we're going to attempt, well, I'm going to attempt to talk about token attacks and token replay attacks and some of the mechanisms that we can put in place to protect, protect ourselves from some of, some of that or prevent replays and things like that. So I think that's the gist of it. It seems to be, you know, an emerging attack sort of coming, coming out now outside of just, you know, scraping or harvesting user credentials as the world kind of moves into that semi passwordless sort of world now. So we have to grab something else now.
Yeah. Okay. Do we want to start just sort of, you know, with the basic overview of what authentication tokens are?
Yeah, sure. So I'm probably going to absolutely butcher this, but in effect, when we sign in, when we do a, you know, authentication with, and I'm, I'm going to use the example of using Microsoft technology, you know, we, this is, this is a podcast around here, Microsoft technology, but you know, it's the closest I am to some of this stuff. So using our identity provider in this instance, you know, entra, when you sign in, you know, you, you put in your username password or your username and your MFA prompt, your passwordless authentication, whichever you might be doing, and you authorize yourself. Your machine then receives a token, an authentication token, and this specifies your session, how long you can have it for before you have to re authenticate, but also then tells you, or tells the websites that you can replay it to, in effect, what access you have to various things. And, you know, this is been, I don't know, Sam, it's been like, you know, tokens have been used for many years, haven't they? It's just the technology around them has changed and been more secure and things like that. Is that fair to say?
Yeah, I mean, authentication tokens have been used in web authentication strategies for, yeah, years and years. And I think they've just become more highly targeted because of other, you know, other technologies have come in and sort of added layers of protection to user accounts. Right. So, you know, previously you could, you know, before MFA, you could scrape somebody's or phish, somebody's user details and, you know, gain access to their account that way, sometimes without even them knowing. But now, you know, organization, you know, and your token is essentially a representation of your password, in some respects, you know, it sits on your machine and you use it so that you don't, every single time you talk to the server, you don't have to put your password in. So it's highly sensitive and it needs to be protected.
Yeah. And I guess with tokens may in the past or still currently, you may have a separate token for each SaaS application you may access. So maybe it's only relevant, gives you access to one application, things like that. But as we've moved into seamless single sign on, you doing federation with a single identity provider to bring that experience of not having to have multiple passwords, multiple MFA solutions, things like that, they then become more, let's say, appetizing to sort of grab because it may give you access to multiple things. Now we have, there's various mechanisms to even to collect, not to collect, but to generate that token. We have things like MFA conditional access and that sort of stuff to then try and prevent a token being created and then, you know, then being used by a bad actor. So that's kind of, I guess, an overview, very high level and probably quite butchered from my site around authentication tokens. And I guess another sort of view of it is, I suppose you could kind of say it's like your id badge that you may log into a building, that kind of stuff. It's the same badge that can get into various rooms kind of thing, and if it did get stolen and so on, has access to the locations you have. It's a kind of similar thing as that.
Yeah. Imagine, let's say you visit a new office block and you've got a visitor's badge that gives you access to certain things. You have it so that you pass your forced authentication challenge. You know, the person at the front desk, which is your, your login, you get your badge and then, you know, you can use it until it expires. Right. You know, so, yeah, that could be very valuable if somebody else had access, you know, to that badge.
Yeah. Okay. Okay, so, yeah, can you just expand a bit on sort of, you know, what, what token theft is and you know, you know, and how tokens are replayed during attacks.
Yeah. Okay, so token theft, as it sounds, is the theft of an authentication token. And generally this is normally done in various ways. And kind of the main one is to get someone to sign into a fake or partially fake sign in page for a identity provider. So in our example, Microsoft entra. So there are some tool, there is some tooling out there and it's something that me and Sam sort of tested out kind of understanding that sort of process I guess of how you could potentially steal a token and then work the other way around. Kind of like I suppose that's kind of like red team and then also like blue teaming the other side about how can we prevent it. So in effect, yeah, someone signing in to a website and this is kind of where I was leading to was that previously we, you know, a bad actor would try and grab the, the username password but now with password authentication they now can't risk, you know, collect the password. But what I've seen or what we kind of seen around it is that you know, going through authentication still authenticates legitimately against 365 and your Microsoft tenant, but may look completely identical to the, you know, to the Microsoft or entra sign in process. And that's more around it's kind of is a man in the middle attacking effect but it's just relaying back what Microsoft are you know, presenting to, to the user. But the only difference is that there may be a different URL. So without someone knowing specifically they're a wrong, you know, a, you know, attackers URL you actually wouldn't notice at all that sign in process. And that's kind of what we seen when we were doing some of our testing. So as part of that once you sign in authenticate it then redirects you back to 365. It is then captured the token on the way through and then that in effect then that can be reused on another machine or anywhere else until that token expires. Some configuration could be set to never expire, be persistent. So that token never, you know, in effect, you know, dies or expires. So then potentially could be replayed in other places. In effect this kind of attack is sort of two parts. So one is you know, collecting the token which is token theft but then you've got token replay which is as it sounds, reusing that token to then sign in on a browser. So logging into you know, going to the portal, you know, the enter a page to sign in and then replaying the token against to enter and then it letting you sign in and then giving you access, the same access as that user. And you know as part of our testing, to be fair it was quite, for me it was quite scary how semi simplistic it was. There's, there's a lot of things around it you'd have to do but I, the actual user experience of it and seeing it actually, you know, it taking place in effect you know, like I said without knowing that you're a different website, you would not know. It would be very difficult to even identify as a user. Would you agree with me, Sam, around that when we were doing our testing?
Yeah. Because essentially the login page is identical, isn't it? It even pulls in your branding. You know, that your company set, that's. Kind of what I was saying previously was it's not actually a website been generated. Exactly.
I think it's actually just replaying back what, what. It's almost like a reverse proxy almost, isn't it? That is taking place. Actually the, the bad actor isn't, you know, creating a fake website or anything like that. They're literally just re, they're just man in the middle in effect the attack. So it's just, you know, everything's coming from the, you know, the legit, the, the legit, their legitimate, you enter a new website so you, again, you can't really see it.
Yeah. And then as soon as they've got that, you know, since they got that token it's, yeah, fair, fair game. How do attackers actually utilize that token? Do they make it easy for themselves to exfiltrate and use it? Because I suppose, you know, how do you use a token? Because it's used behind the scenes, isn't it, by applications? You don't see it as a user, do you?
No. So there, I've seen, so the way that we were, I was testing it was that there is actually a plugin for editing or modifying tokens. I think there's more of a legitimate reason for probably dev testing applications, things like that to understand what the tokens are kind of thing. But in effect you can just load your token into that browser extension and then just refresh the page and then that token is then presented to the identity provider and then you're signed in to. This is really only targeted at browser sessions. It's not around office, you know, applications themselves. So I think it's quite difficult to probably steal the tokens from that and replay them at least into an application there. I might be wrong on that but I think it's definitely, the main attack is around browser access there.
Yeah, no, definitely. And it's the easiest mechanism, isn't it? You know, it's the most recognized. We use so many SaaS applications that are even SSo. So it is, it's a normal journey for somebody to have to be. It's like, oh, I'm being reprompted. Whilst logging into, they've been sent, you know, a phishing link in a, I don't know, somebody shared something with you on Dropbox. Oh, we use Dropbox. Oh, let me go in. Just sign in. Oh, I've got to SSo again. Oh, that's annoying. Oh, let me just do that quick. You know, it's like, it's very believable, isn't it? You know, so, and a lot of these attacks, the, the domains that they may redirect through are still haven't been picked up by, you know, web gateways and filtering. So essentially zero day at that point, isn't it? Know, nobody really knows what it is.
Yeah. And as you kind of said, as well, you know, even your branding comes through. So, you know, some indicators of whether, you know, it looks different than a normal, you know, entra sign in like you said, or re authentication, you know, you'll see your branding. It looks practically the same. You know, is what is worry, to be fair, is worry about how, how, you know, good it is in some form or how good it can be.
Yeah. Yeah, definitely. Okay, Alan. So, yeah, so I suppose, you know, I don't know, we don't want to put the fear in, into everybody. So, you know, let's hope there is a way to protect against it. So, you know, how organized, how can organizations, you know, you know, reduce their risks of tokens being stolen?
Okay, so as we kind of said that it is kind of two parts to this sort of attack, you know, is the solen tokens in the replay. So for token theft, one part is as we, as we, as every organization kind of knows, it's, it's user training, you know, making sure they're up to speed on, you know, best practice around websites, things like that, because there will be some inconsistency with a website. Yeah, it's always the human factor. So yeah, it's definitely worth making sure that users are up to date on their latest cyber security training and things like that. But from a technology perspective, really it's understanding how someone could get to a malicious website where this could take place and collect credentials or the tokens. So this is kind of putting in technologies to prevent even the user getting to that point. So this is kind of talking around secure web, no secure web gateways, but. Well, potentially, but I'm more talking about secure email gateways. So defender for Office from the Microsoft kind of play, you know, the, the mime cast, the, the proof points out that kind of stuff and the various other ones. Being able to prevent a phishing email even getting through to the user is sort of your key or primary sort of prevention of token theft. Again it's, it's not, I say just email. It could be a file that's come in from a usb pen, from third parties, things like that. You know, all the various ways that someone can click on a link and then it will ask them to sign in. So that's one part around email. The second part is probably, you know, a secure web gateway that's looking at threats, checking the, the URL's that you're actually going to on the device with defender for office you have got safe links as well which is kind of part of that. But the second part around email, school web gateways and actually preventing users to go into, I say, random websites that aren't agreed by categories and things like that. So really it's all sort of prevention of the user even getting to the point of signing in. The other part to this is there is if a user does get to, you know, one of these websites and does put in their credentials there generally isn't a way as far as I'm aware to actually prevent the token from being taken as soon as they sign in outside of preventing them even getting to that website. Same thing with, you know, if you're using, trying to prevent you harvesting credentials, your username, password, if a user does get to it, they are, you know, they have been taken. There's nothing, I don't think there's anything around the endpoint or anything like that that could prevent it outside of anything being on a, you know, from threat intel that knows it's a bad website and that kind of stuff. One thing we have seen some, an organ, a couple of organizations out there or services do and we did test it ourselves, in effect building our own, is that you can do some, some, what is it Sam? Some CSS coding on the, on your login page that in effect detect or try to do some detection about what, where the, where you're signing in from and where you've been redirected from in effect. So that you can then detect that and maybe change some of your branding to indicate that maybe this isn't a trusted site. Is that fair to say, Sam? I've probably done that not very much justice.
Yeah you can, on the sign in page you can set, you can set a JavaScript payload, I think that's what it is. And at that point you can sort of see where you've been, what's called referred from. So there is a referrer URL which is passed through which is essentially where have I come from. It's how websites like track you. Well used to, I suppose there's a lot of anti privacy protections in place now, but it's basically how websites used to know that you came from, come from Google and things like that. So what you can say is you can say if my referrer isn't login dot Microsoft.com or something like that, then you can dynamically, it's not some JavaScript, you create an endpoint which returns an image which is going to be used as your background image. And then when you request that image from your endpoint you basically say what's my referrer if I'm coming from the login page? If the image is being, for the background is being requested from the login page then. So maybe show a green tick or something like that on the background. If there's any other URL then return an image which shows to the user that it's unsafe to login at that point because the URL will be incorrect, it won't be the correct referral URL from Microsoft. So, so yeah, so yeah there is, there is a way to, to do that and you can, how did we do it? Did we do it with a, do.
A function app, didn't you, or something? No. You want to function up or maybe an API manage management instance or something like that. I think it was a function app. Yeah, I think, I can't remember but yeah, yeah. So it, it does require some technical ability to do it but it is relatively simplistic. I did ask the question of is why is this not built in? It seems crazy that it's not, but it isn't currently today.
Yeah. And there are some companies out there that actually provide a service that look after that for you in effect, and have, you know, service that you can sign up to and they tell you what to put onto your, onto your identity provider. You know they, they cover multiple IDP's and then you can actually, they can give you a report or give you alerting if someone goes to it. They might not be able to know who goes to it but I think they can determine potentially the IP address that they've come from. And yeah, what website is cloning is in effect cloning you? So really that's kind of the only way to inform the user at the time or as a prevention to put in their credentials in, in this sort of sophisticated attack where in effect you really can't tell, especially if you're not looking at the URL kind of thing.
Yeah. Because the sophistication of the proxy means that they do actually pull through your branding. So that does give you an ability to understand if your branding is being shown on a domain that isn't the Microsoft domain. So in some respects, if they built their own, they didn't use the reverse proxy then, but they wouldn't be able to have such a sophisticated attack. If that makes sense, it actually works their detriment. So, okay, so, you know, we can't. I don't think it's right to rely on. It is. I don't think we can be 100% because we've got some sort of multiple lines of defenses here, haven't we? We've got defender for office or some sort of threat protection service on top of your email. That's. .1 I think probably next is phishing awareness and training. You've spoken about that, haven't you? Then we've got IOC's threat intelligence which feed into your secure web gateway. That's protection number three. And then I suppose you've got a little bit more of anti phishing guidance there because you won't be looking at a legitimate URL, will you, whilst you're logging in. And we've also got the branding protection that we can do. So if all else fails, let's say you don't have those things set up or, you know, or somebody completely ignores them because there is a human set on the other end. And I don't want to be too critical of any specific humans, but just generally we do sometimes like to not follow procedure right, or be caught off guard, etcetera. What can we do if a token has been stolen? Can we actually, is there any protection that we can do after that event has actually happened?
So, yeah, so from a. And again, I'm going to take the stance on enter and conditional access side of things. So yeah, there are protections in place that can protect as best they can around the replay of the token. And mainly the main mechanism is the continuous access evaluation, the CAE sort of capability that entra has around conditional access. So continuous access evaluation, in effect, detects when a user has changed IP address device, things like that, and then just checks whether the token is still valid against that sort of mechanism. And that's dependent on, in effect, it forced a revaluation of conditional access. So it just says, in effect, you know, something's changed. Let's recheck conditional access. So with conditional access, there may be a different condition, which means they have to do a different MFA prompt. So maybe if it's outside of country, you know, where the organization works, there might be a block there. So that will then prevent the token from being replayed in another country. Bear in mind that a bad actor could use a VPN and, you know, get into the country, into the same region or the country that you sort of reside in. They could potentially still use that token there. Some of the other checks within conditional access, like I said, there may be an elevated MFA prompt when you're nothing, when you're in a certain situation or when accessing certain services. So maybe you've just done a standard MFA notification and now you need to do a passwordless one or a phishing resistant one. So elevating your, your level of authentication, in effect, that's another mechanism there. Within conditional access. Another part is named locations. So again, specifying which countries you can come from, but also maybe you're specifying that actually, you know, come from the, the office IP address via a VPN, things like that. So that can start, that can also prevent it because again, continuous access evaluation kicks in, determines you're not, you know, on the IP address or coming from an IP address that's trusted, and then you're doing a re evaluation, re running through your conditional access to validate whether you're allowed access or nothing. So some of. So some of those are fairly, seem fairly simple, but can also be quite restrictive, you know, being, forcing organizations to be at specific IP addresses, things like that means that moving around, requiring, you know, VPN's in place to validate that can be, you know, potentially costly because you have to have a VPN service there to, to manage that. The restrictions on, you know, which countries might not be somewhat realistic because you might be multi, you multi region multinational organization in, in everywhere, you know, in every country or majority of countries, there may be countries there that you actually do or not, you definitely do not want access from and that kind of thing. But there is one other sort of technology or solution there as well that can help be a little bit more flexible around it. And that's around the global secure access from entra. So this is around the Microsoft 365 forwarding profile. In effect, this is traffic in effect, VPN. Youre Microsoft 365 traffic two to the global secure access network and then going via Microsoft out to, to 365. And yeah, to 365. So that all seems okay. But what that does is if you come from the global secure access network, in effect, there's now a new condition or a new network location in the network, sort of conditions in conditional access that says a compliant network and that is global secure access. So a user can still move around and use global secure access because global secure access today needs to be on a managed device, you know, an entry joined or hybrid joined device to work. So it's, you know, it's guaranteed to be one of your machines excluding the scenarios of, you know, someone storing a laptop and things like that. Because that is, you know, in country kind of stuff. And that again, remote wipes can prevent a user actually using the device and things like that. So you know, it's from a managed device, it can then sign, you sign into the client and then you can tick that box saying that, you know, to access 365 you have to come, come from this compliant network which is the global score access network. So that allows flexibility to move around to a cloud service without having to be tied to, you know, Microsoft 365 traffic, having to go to your organization and then back out, saving on dependencies on your network equipment to access 365 and things like that. It gives a lot of flexibility. And again, if a bad actor does grab a token, then when they try to use it anywhere, even in country at that point, or trusted countries and things like that, then it is in effect invalid to them. So I think that's quite powerful from a flexibility perspective. Yes. Depending on what licensing you're at, some of that capability is included. So it's not necessarily an uplift in licensing. Well, which I think is quite cool and key as well to add an extra layer to try and prevent the tokens being replayed.
Yeah, definitely. Yeah. So essentially what we're saying is that you've got multiple, you know, layers of protection really, haven't you, that you can, you know, you can actually layer in place.
Yeah. And like I said, some of are quite restrictive and preventing you from doing certain things or allowing users to do certain things, you know, being more flexible about where they can work and things like that, or what process you have to go through to gain access. So there is a trade off between complexity and, and usability and security that kind of the whole world of, you need to do what's best for the organization so that you can still run in a, I'm gonna say, productive way, efficient way while still being secure. And one thing I kind of forgot as well, I didn't forget I was going to come at sort of now, was that you can also set a token expiry date or time on it, so you can say, you know, it's valid for one day, it's valid for a week kind of thing. So if there are some sensitive. I think you have to set that across all your services. In effect say this is a token that expires after maybe 24 hours, so someone has to re authenticate. And again, that might be, may seem inconvenient to a user, but as we bring in these mechanisms to single sign you in on your device because of hybrid join, Windows hello for business, all that kind of stuff, the user never really sees it or it's not a burden on them because the MFA prompts and things like that are done for them previously, especially Windows hello for business. It's very seamless at that point. So you can be very secure and still have a good user experience for the user as well.
Yeah, definitely. I think it's about making the necessary trade offs in your scenarios, isn't it? And how the sensitivity of what you're protecting and what sort of resources you've got available to you to lock things down. But yeah, there is definitely ways to layer on security.
Yeah. And actually just thinking about it when we were doing our testing, we also found that recently there's been a new security alert within Defender XDR and I'm guess it's come from identity protection at this point. Or it's a combination of identity protection defend for endpoint, defend for office, and probably defend for cloud apps. Actually around that, that actually it comes up saying possibly a token theft or replay of a token there. So again there is some alerting and you know, in the background of Microsoft trying to work out if something has happened around a token and then that alert can then go to your, to your SoC, to your managed SoC to then do investigation, reset tokens manually, you know, reset sessions, etcetera to prevent, you know, to prevent that access as well. So you have got that part as well into, in the, in the mix.
Nice. Anything else you want to cover, Alan?
No, I don't think so. I think there's lots of tools within the identity providers. I'm going to be semi gen, you know, generalized with that. But I've, you know, as I've kind of talked about, there's a lot in entra to help. Like you said, put layers of security to one, prevent the user even getting to the it and then the token being stolen, but also the, the replaying of the token if it ever does get stolen. So you've kind of got your pre beat, pre breach and your post breach kind of tooling there I guess, as well.
Great, thanks very much for that, Alan. That was a really good overview and yeah, definitely a popular topic at the moment for unfortunate reasons. Yeah. Okay. What's the next episode? Sam? Yeah. So next episode for us is going to be the news. So we'll be covering. Our next episode will be early October covering September's news.
Nice. Cool. So did you enjoy this episode? If so, please do consider leaving us a review on Apple, Spotify, or YouTube. This really helps us to reach out to more people like yourselves. If you do have any specific feedback or suggestions for episodes, we do have a link in our show notes to get in contact with us. Or you can put a comment on one of the episodes. Yeah, and if you made it this far, thanks ever so much for listening, and we'll catch you on the next one. Yeah, thanks. All.