Device Code Login Phishing Presentation Attack, Detect, Mitigate

Key Takeaways

What's going on YouTube? This is IPSC and we're going to do something a little bit different today and just talk about device code fishing. Starting with this article from Microsoft Thread Intelligence. After this article, I'm going to bring on a friend. We'll go over a presentation we made on device code fishing. A little bit of the history, how to set it up and other things. Then we'll do a live demo, show you what it looks like in the field. And then after the demo, we're going to talk about some blue team things like how to detect and prevent it. So, with that being said, let's just get into the article titled, "Storm 2372 conducts device code fishing campaign." And right off the bat, I kind of dismissed the article because I'm a bit numb to fishing campaigns. It's hard to do fishing and make me interested nowadays. However, I didn't know what device code fishing was. I didn't even know what device code login is. And looking into it, it's essentially um think back when you like set up a Roku, Firest Stick, Nvidia Shield, something hooking up to your TV. You install a bunch of applications like Netflix, Hulu, Amazon Prime Video, things like that. And then instead of typing the password on the remote, it props up a QR code. You enter some digits and then um share the authentication from your phone to the device. That is essentially device code authorization. And many things support it because it's just part of like OOTH. And oddly enough, Microsoft Office does support device code login. I don't know exactly why, but we'll look into um why it makes for such good fishing attacks. So, right here, the article looks like it was updated February 14th, which is about a month ago. They're talking about storm 2372, which is just um Microsoft designations for unknown threat actors. They're like new emerging. They believe it is Russia based upon the interest in Tradecraft, but they're not 100% positive. And then Microsoft saying um the fishing lures use Microsoft and other apps to trick users. However, there's no vulnerability in our code. Everything is good. So um it's kind of funny because Microsoft is starting to like remove device code authentication from clients that don't use it. So even though there's no like real vulnerability in the code itself, they are making some changes which is good. Um, right here they're just talking about who Storm 2372 is targeting, which includes government, non-government, in IT services, uh, defense, telecom, uh, health and higher education, energy, oil and gas, Europe, uh, North America, Africa, and Middle East. So, they're targeting quite a bit. And right here, they're talking about device code fishing. The threat actors exploit device code authentication flow to capture authentication tokens. And this doesn't sound too scary, but it's your whole like authentication to the office suite. We'll show after we capture these tokens. Uh we can download email, we can log into office 365, go to team, shareepoint, whatever. And I also think if like you use external services that have SSO like Confluence has signin with uh Microsoft online, I think this token can actually let you log in there too. And if the user has MFA set up, you're not exactly protected because the authentication token doesn't have MFA. That being said, when the user clicks on the link, if they're not logged in, they'll have to enter their MFA token. But in this case, thaces don't have to do any like man the middling to extract MFA. MFA doesn't make the attacker's life any worse in this case. So, um, the fishing attack identified in the blog masquerades as a Microsoft Teams invitation delivered through email. And before going here, let's just scroll down to exactly what it looked like. So, here they're talking about they start the conversation off through outofband communication to gain a little bit of trust using either like iMessage, signal, or text messages just because um it's easier to trick users and fishing that way. Also, when you use outofband communication like signal a iMessage, chances are the corporation can't monitor it. Right? If I just um spearfish a bunch of users in an organization, the CIS admin can get alerted to that because they can read the email and then know some type of fishing campaign is targeting them. If you do it through out of bands communication, then it can't really see anything. At least how it starts, right? And this is the invite. They say, "Hey, you want to join a Microsoft Teams meeting with us?" You click the link and then you enter the code. This is what the page looks like. And if you enter the code here, this is what's giving full access of your account over to the attacker. And after reading this article, it sounds scary. So my next step was to understand device code login. So I know if this article is just fear-mongering or has some legitimate basis. And believe it or not, I'm not a cloud guru. So I asked my good friend OD. And he sent me some posts that helped clear it up. and he did such a good job explaining and demoing this attack that I figured I'd bring him on to help show all of you. So, welcome OD. Please talk a little bit about the post you had sent me. Sure. So, to understand how device code fishing works, we can look at three additional pieces of research. These articles do a really great job of giving us the full picture on how the attack works, how it's used in real world campaigns and then how we can detect it. The first is this blog by Vexity and it does a really great job of diving into the social engineering pretext that these threat actors were using and specifically how they're sending some of their fishing lures via signal to their victims. This article came out the same day as the Microsoft threat intelligence blog as well. Now on the detection side, we have an amazing article by Lena Laauo Averse Cause on detecting malicious device code fishing. um she provides a lot of great information on the defensive side, especially how to detect if the attack has taken place in your tenant. Then also, you know, how you can prevent against it. Finally, we have probably the most well-known article on this specific attack and that is art of device code fish by Bobby Cook. And he does again an amazing job of starting and detailing the attack from start to finish, step by step, providing a lot of clear instructions and reasoning about how to conduct this attack. He even has some great details on how to set up fishing infrastructure as well. Yeah. And the crazy thing here is just look at all the dates the articles were published. Bobby did this in 2021 and attackers are still having success with it in 2025. What is old is new again. And the main thing we're seeing is thread actors are changing up how they start the fish. It's no longer starts as an email. They're trying to start over outofband communications such as signal messages as it's harder to monitor and users are immediately suspicious about emails. My most successful techniques is using ad campaigns on services like LinkedIn or Twitter to target companies and get users to initiate the conversation with me because if a user starts the conversation, they're not expecting me to turn around and scam them. But 2021 wasn't even the first time this was talked about. So tell us more about the history. Yeah, so the attack was originally introduced back in October 2020 by Dr. Azure ID. So 2020, we're we're going on almost 5 years now. And in his blog, he goes over how attackers can use this legitimate device code authentication for their fishing attacks. And what's really great is he's also incorporated this attack into his AAD internals PowerShell toolkit, which if you haven't heard of it before, it's an amazing resource on all things pentesting, Azure, M365, and he also has a lot of administration functions built in as well. Yeah. And the important thing to note here is we'll keep saying hack, tools, exploits, and that kind of does it a disservice making it sound more complicated than it is. We're not really performing any real exploitation. We're just using OOTH device authorization grants and bending some assumptions to set up a really good pretext to fish users. That's incredibly effective because it beats how we train users to spot fishing attacks. We train users not to look at the URL and this uses the legitimate one by the service provider, in this case Microsoft, so there's nothing to see there. We also tell users not to enter passwords into websites and the user isn't entering a password. They're just entering the code we tell them to. It's just a random um nine character alpha numeric code that looks very much like how they join a Zoom or Teams meeting. So, it's just familiar enough to the user to make them not question it. And Microsoft's in the spotlight here, but it's important to note many services support this. Like if you logged into Hulu on your TV, you probably scanned a QR code with your phone and shared the authentication with it. Other service providers do support this. It's a little bit silly for office suites like Microsoft too, but thankfully it looks like Microsoft may agree as they're starting to make some changes. Yeah. So, some good news as this came up again, they took another look at who actually uses this device code flow in their day-to-day work. And what they found is that it this flow specifically is kind of infrequently used by, you know, your typical users, legitimate users, but it is frequently implemented by attackers. So, they're introducing a new Microsoft manage policy to block device code flow. That's going to be rolled out uh in report only mode at first, but after a certain amount of time, it will then be enabled. So, again, super important when uh for you to go check this out over in your tenant, get a sense of if your users are actually you using this as part of their legitimate workflow. If not, definitely begin to monitor it in report only mode and then ultimately move to to keep it blocked. Yeah, it's really great that Microsoft is holding true to their security initiatives they pursed many months ago. We all know how long fishing was a problem in Office docs. Thankfully, Microsoft has kind of solved that problem as I haven't heard of a campaign using fishing macros in quite some time. And this is just now emerging and Microsoft's immediately putting kind of a stop to it or at least giving users the tools they need to stop this. And they're doing it in a good way. Putting in report only mode first and then blocking it if it's not used. That's how you should always uh go about things, right? Because if you go straight to blocking it, chances are um the seauite's going to get blocked and then they'll tell you to revert it immediately. And once you block someone that high up, whenever you try to put that rule back in place, you'll get a lot of resistance and probably not be able to block it again. So, um, always great to just go into report only mode. But first, or audit mode, make sure it's not going to impact users and then switch the switch to, um, block it. Exactly. So to really drive home the point about how this is you know a legitimate authentication authorization flow we can see that two of the most popular applications that interact with Azure resources have this as an option. Right up top we have the Azure CLI and we have the use device code option for us to authenticate via that method. And then on bottom we also have the a PowerShell application and we can use that again to authenticate with device authentication. So again nothing inherently malicious with this flow but it's really easy to abuse. And before we get into the abuse though let's look into this flow in a little bit more detail. So generally what we're going to do is kick off our authentication on one device. Let's say we're on a remote server. We'll use the Azure CLI to begin our authentication process. We're going to start it over there and then move over to a secondary device where we'll complete that authentication. So, let's say we're using Azure CLI. We kick it off. It's going to reach out to the device code endpoint and we're going to get a couple of key pieces of information back. The most important for us are the user code and the verification URI. Yeah. And the V verification URI is just a URL that Microsoft gives us and it's going to be static for everyone. The first two on the screen are going to be URL shorteners that point to that third one. And really that's just where the user goes to enter the user code. So um really only one piece of dynamic information that is the user code. Exactly. So what we're going to do is visit that device loon page. We're going to enter our user code and then we'll complete the authentication process there. Meanwhile, back on the original device, we have the Azure CLI continually reaching out to that token endpoint and checking to see if the authentication has completed over on the other end. Once it has, we're going to get back uh again an access token, a refresh token, an ID token, and we will have finished our authentication on that server. We can now use Azure CLI to begin to interact with any of our Azure resources and conduct our usual work. So now, let's hop over and get into a live demo of this working. I'm gonna be the victim and Ryan's going to command the attacker's machine and he's going to fish me using device authorization grants. So now, like IPSC mentioned, we can get into how the attack actually works. And what we're going to do, uh, first of all, check what directory in because we want to import the token tactics module. And the reason we want this is because we're going to be doing some token manipulation as well as using the get Azure token uh module that this has built in here because this is how we're going to initiate our malic malicious device code authentication. So as you see we started that off. We specified that our client is graph and let's see what we got back. The most important thing for our malicious use case is we can see that we got a new user code. This is what we're going to now copy and take over to our social engineering um fish that we're building. And for our purposes, right, we are going to use this fake kind of teams message. This is a team's invite, but we're going to change the passcode to be our malicious user code. So, this is where we're going to try to get them to enter into the screen because we've also changed the join this meeting link. And if we take a look at it, we can see that we've changed it to the device login endpoint, which is that login URI that we were mentioning earlier. So, we've changed both of those things, which together should allow us to trick IPS into him sending us our token. So, we're gonna send that off. And it's gonna take a second for it to hit my mailbox. There it is. we see an urgent request to join. If we click on this email, it looks very much like a normal team's invite. It's scheduled with a little bit of urgency saying there's a meeting to discuss the MDR to optics um design. And it wants us to join the meeting now. So, let's go ahead and copy the passcode because we know we'll need it um in just a second. And we're at this page. If we look up top, it's login.microsoftonline.com. No typers or anything. This is Microsoft's legitimate page. and it wants us to enter the code to allow access. It's not really specific on what it's saying to allow. If like if I'm the user, I'm just thinking, hey, this is to allow access to the meeting. Um, it should probably say like this is going to give the um recipient full access to your account, right? But I'm just going to paste the code because I'm not typing my password. I kind of trust this, right? It's just a Teams meeting. And now it wants me to pick an account. I'm already signed in. If I wasn't, this would prompt me for credentials. But most people are going to be signed in if you send it during the workday. And it says, are we trying to sign into Microsoft Office? Yes, I'm trying to access Teams. I'm logging in and I've just clicked continue. It says I've signed into Microsoft Office application on my device. I may be a little bit confused here, but at this point, it is too late because we're going to go back over to the attacker screen and see the token has been acquired. Yep. Perfect. We can see that uh the authentication flow has finished and we have our token saved in the response var variable. So what we can do is use this parsing function from token tactics v2 and take a look at whose token and we'll get additional details on about this token. So we can see here the most important parts are that the unique name and the UPN the user principle name are for the IP atazpurp.com. So we know for sure that we have successfully fish our victim user which is perfect right. So now now that we have that right, we can begin to conduct some reconnaissance and enumeration from an authenticated standpoint. So we're going to import the AAD internals tool set that we mentioned previously because this has a lot of great functionality to be able to do this enumeration. One of the first things we might want to do is get a list of all the users in the entry ID environment. And you can see here that we're using that commandlet and we're specifying the access token from the response. That's how we're going to authenticate into our victim tenant, right? Get a ton of information back. We can see people's job titles, their addresses, right? The address information is going to be crucial, especially as we're trying to potentially get around any conditional access policies that might be blocking us. We can also get addition additional information on um job descriptions and everything else like that. So what we can also do is get information about specific users as well. Say we're targeting the Lydia user because that is the chief sales officer. We can specify her specifically and get more information about her as a user. So a lot of ability there. But it doesn't end there. He's now going to run the refresh to Outlook token and that's going to give him the ability to start pillaging my Outlook information. So, right now you're seeing he's changed the scope and he's got full access to Outlook. The next thing he's probably going to do is try to pillage my emails. Yep. Exactly. And a great tool to be able to do that is GraphRunner by uh I believe his name is Bo Bullock uh Daft Hack and it's an postX tool used specifically for M365. So, we're going to import this and then use a couple of the modules from his to tool set. But first, what we need to do is get our token into a uh version that is expected here. So, let's clear that out. And we just we just did that as well. So now what we'll do is we can use this get inbox command lint with and specify our tokens specify our user and pillage and receive all of the emails for that user. And there you have it. He's dumped all the emails. Now I haven't been an employee that long so it happened relatively quickly. And right at the um top we see the temporary credentials assigned to my developer environment. But if someone was an employee for a long time, their mailbox may be gigabytes big and take a while to download. So um there is another command that enables you to just search mailboxes. It's invoke search mailbox and allows you to specify a search term. He's going to use the search term credential. And now it's going to search all my emails for a phrase called credential. It finds the one that he's looking for with temporary credentials. So he could potentially access the developer environment from there. And if he wanted to, he could save the email. He's just going to do no. And it doesn't end there, right? We've shown a lot of the command line stuff, but if we want to, we can convert this token into one that a web browser likes, and that's going to enable us to um access like Office in a way that's familiar to most users. We can see OD is putting out the refresh and access token because he's going to need both of those pieces of information to put over into his web browser. He's going to go to Burpswuite where he has preloaded the request. This came from a trusted um SEC article, hacking a cloud. The link will be in the description below, but he just put the um access token in. He's putting the refresh token now. And then when he sends it off, Burp's going to give him a 302 redirect. Then he's going to play in his browser. He's going to get an error message. It's going to look like the attack didn't work, but you'll see he's just going to refresh and magically he'll be let in. So there he goes sending the request. There's the redirect. And now take it away, OD. Yep. Exactly as you just explained it. So, we're expecting that 302 error. So, what we're going to do is rightclick, open a browser, copy there, and then we'll head on over to our browser. Make sure we click the incognito one. We will enter that in there. We're going to get redirected. This is what we're expecting. So, what we want to do is then disable, turn off our proxy, and all we have to do from there is refresh from this error screen. And we are now authenticated as our victim user. And we can perform additional reconnaissance from here. We can do other business email compromising type things. We can set Outlook rules. We can search for additional credentials. We can send more internal fishing emails to other users. Right. We can start sending emails to, you know, the seuite. Do what else do anything else we need to do from here. Yeah. And we're fully logged in as a user. We don't even have to keep using emails. We could switch over to something like teams and just send messages. Now, if he just goes to teams from this window, it's not going to work. You'd have to do some more token tactics type stuff to get the right token because as you saw before, we're granting access just to Outlook. Um, but also uh we could access other like single sign on services. So, if the company used like Confluence, we could trick Confluence to saying, "Yep, we're logged in as that user and just gain access to that." So, really dangerous stuff here. He's completely hijacked my Office 365 account. We've seen it from the attacker. We've seen it from the victim. Now, let's go and pivot over into an admin user so we can look at what it looks like from a defender perspective. Because as scary as this is, it's something that's easy to detect because device authorizations probably aren't happening your organization. So, everyone you see is suspicious. It's relatively easy to filter by. And yeah, let's just go pivot and look at what it looks like. So, here we are. We're at the sign-in logs. And this is where we're going to start because this is available to everyone. the other things we mentioned later on in this video. That's going to be add-ins and things like that, but signin logs is the easiest and it's available to everyone. So, it's a natural place to start. We're going to create a filter for the authentication protocol of a device code and that's going to show us all authentications that are device code login. So, we click on authentication protocol device code and here we go. Hopefully, you see zero when you do this. Uh we have quite a few because we've been doing this demo for a while. But we can see the applications Microsoft Office. And if it's a legit one, it probably won't be Office. It'll be something more scary like Azure CLI because I don't think there's any way for users to initiate this through the um interface. It's something you have to do on the command line. And uh we set it to Office for uh purposes. But the key thing I wanted to mention is the authentication protocol we see down at the bottom that's set to device code. And then there's something called original transfer method and that's just going to be how this authentication started. We're at the very first step. So of course it is device code but this becomes important when we go to the non-interactive signins because we did a lot more authentications in our attack. We use that um token tactics to refresh a token and change its form. Right? So we're going to create a filter for original transfer method and then specify device code flow and that is going to um show us all the authentications that started here. And if we click on our self we can see additional details about this um mainly looking at the client app. This is browser but we can go down. We see original transfer method device code flow. That makes sense because that's what we filtered on right and now the authentication protocol is set to none. I think it's set to none whenever you do like refresh tokens, things like that. I'm not 100% positive what all these fields mean. The Vexity article we talked about earlier does a great job talking about that, but I'm going to kick it over to OD. He's going to go into Sentinel and talk a little bit more about the advanced things you can look at. Yeah. So as uh EPSC did a great job of mentioning right uh those signin logs are available to everyone but if you do have uh some of the advanced things like defender XDR or if you have Sentinel as a seam and you have these plugins enabled it can give you um some additional options to look for some indicators. So one of the additional indicators mentioned in the lean allow inverse cause blog is this CMSI endpoint call. So we were doing a little bit of digging. We don't want to get into it too much, but it seems like everyone is in agreement that this is like an additional indicator for this device code authentication fishing attack. We think it's for the uh check my signin, which was that little popup page that shows like, hey, are you trying to sign in to Microsoft Office? And then you select yes. So definitely something to check out during our testing. It was um pretty pretty useful for that as well. And the original query is from uh Bert Jans. So check out his repo. But now, and real quick before we get into that, um I just want to highlight one cool thing. The where empty uh AAD device ID, the AAD stands for Azure AD. So that's just going to be all managed devices. That is a really powerful thing to do just to filter your queries on devices that were not um managed by your organization. So definitely check out um that a little bit more and you should have a conditional access policy blocking unmanaged devices from accessing your tenant. So now for additional kind of indicators and for hunting purposes, right? We can check if we have these email events enabled in our seam in our defender portal, we can look for any of those verification URLs, if they've been sent in any emails in our tenant. What you can see is that this is a great indicator because, you know, we wouldn't see this um we don't expect to see this, right? Like users shouldn't necessarily be sending each other this. It's not something that would come up as part of any other type of email authentication. So you can see here this was our malicious teams invite that I sent IPSC right and right here this is that final uh verification URL endpoint that we authenticated against. Again another great additional piece of information you can look for if you are suspecting that this might have taken place in your tenant. And this is just a really good way to keep tabs on emails of your users without actually uh violating the integrity or confidentiality of the email, right? Because we're not reading the contents of the email. We're just reading the subject and the recipient sender and then just extracting all the links so we can make sure users aren't being directed into inappropriate places. So definitely a great thing to look at. And now we've looked at a lot of just all the detection, but hopefully you don't have to get to the detection point because you can do preventative and this is going to be much easier to do. Exactly. So checking for these indicators, you know, can be a little nuanced, time consuming certainly, but the good news is that we have a very straightforward tool to be able to prevent this attack, right? And that's where we can make a conditional access policy to block this device code flow. So let's pretend to set one up and go over what that might look like. So first, as best practice, what we probably want to do is select all users. Now, this is important because even if we find instances of our users employing this legitimately in our tenant, say we have developers that need to use this, we can make a targeted exclusion rule, put them in a group. That's best practice, right? I don't have even a group right here, but um we can put them in a group and then exclude them for the policy. Now, make sure to review that group occasionally, right? And make sure that it's up todate and not overly inclusive. But again, that is how you'd want to kind of configure this if you even have it. Otherwise, you should most likely block everyone. And this is how you should do any type of firewall. If we went back a couple decades and just looked at networking and firewalls, um network administrators used to block specific protocols like I'm going to block Kazah, Limeire, and torren for my network. But now over time we decided, you know what, block lists aren't really that good. We switched to an allow list where we just block everything at first and then allow what we want. So we're going to block everything and then let's allow um HTTP through because that's what users need. So just really best practice of what industry is at right now. Exactly. And then similarly, what we want to do is configure this um for all resources. Again, I would rather be on the safer side here. I can't necessarily think of an instance. You could also lock this down further again if you have legitimate users. um and you can like filter them to that specific application that they need. Now, probably the most important part is if we go down to the conditions tab and we scroll to the bottom, we have a authentication flow option here. And this is where we can select the device code flow specifically, right? We can use this and highlight it for our authentication and authorization protocols and the different grants it's doing and highlight this here because we ultimately want to do is if we go to the grant pane is block access right so with these two things um and our users configured right this will block this device code flow in our tenant which is exactly what we'd be looking for and one of the new things Microsoft has put here we it in preview mode right now is that view policy impact. That's going to take a approach where we can see the um hypothetical um standpoint over the last seven days. So we can see how effective this policy would have been. And of course before enabling the policy, we should leave it in report only mode, save it, let it run for a week, make sure we're not blocking anything that we don't want, and then just kick it on when um we are confident the policy is tuned well enough. So, that's going to wrap up the video. I hope you guys um enjoyed it, learned more about this device code login things. Let us know in the comments if you enjoyed it. But that's going to be it. Take care and we'll see you all next