ARToken: How attackers are bypassing MFA and maintaining access

MFA and password resets aren't always enough.

That’s terrifying for security teams today. In this episode of Talos Takes, we dive deep into ARToken, a sophisticated phishing/BEC-as-a-service platform that steals credentials, bypasses MFA entirely, and leverages primary refresh tokens (PRTs) to maintain persistence in your environment long after a password reset. This turns a simple phishing click into a long-term breach.

It’s time to rethink your defenses. Join us as Cisco Talos Threat Researcher Michael Kelley breaks down how this new breed of automated attack works and, more importantly, how you can spot it. From hunting for suspicious device authorization grants to securing your cloud infrastructure, don't miss this critical look at the new frontier of business email compromise. 

Blog: https://blog.talosintelligence.com/artoken-inside-an-eviltokens-affiliate-panel-targeting-microsoft-365/

Transcript

Amy Ciminnisi 0:00

Welcome to the Talos Takes Podcast, where we discuss Talos latest research and security news. This podcast is for everyone, from the C suite to the front line. Welcome back to Talos Takes. I'm your host, Amy Ciminnisi. In Talos's 2025 year in review, we noted that phishing attacks were used for initial access in 40% of Cisco Talos incident response cases. And phishing attacks also largely leveraged valid compromise credentials to launch lures from trusted accounts. Today we are talking more about phishing. We have spent years telling users that multi-factor authentication is the gold standard to keep accounts safe. But as some of our researchers have seen recently, attacks often evolve faster than our defenses. Today I am joined by Michael Kelley, Threat Researcher, to talk about his recent research into AR Token, which is a phishing as a service platform that bypasses MFA and it also uses primary refresh tokens to maintain persistence even after a user changes their password. Michael, how are you doing?

Michael Kelley 1:16

Fantastic. Cannot complain. How about yourself?

Amy Ciminnisi 1:19

Doing pretty well, thanks. Really excited to dive into this. This blog is pretty crazy. Um, we've been tracking phishing as a service for a while, but this R Token panel feels like a real step up from what we've seen previously. For the listeners who haven't had a chance to read it yet, what exactly is our token and why did it stand out to us enough to warrant a deep dive into it?

Michael Kelley 1:45

Yeah, so our token is, I would say, a little bit more than a sort of phishing as a service panel. I think historically, you know, phishing kits and phishing as a service as sort of a label isn't outside the norm, uh, but there's an expectation with that comes with that. Um, but in this case, what makes this special is it's more aligned with a almost a business email compromise, you know, as a service platform, uh simply because, you know, we're not talking about simply guiding the user of this platform through initial compromise. We're guiding them, the panel itself is guiding them through both the compromisation of credentials, maintaining persistence, and then through the UI, sort of informing the attacker that's using the panel in all the different ways they can leverage it from interacting with uh SharePoint, um, you know, OneDrive, et cetera. And what not only that, but a lot of the back-end APIs were heavily aligned with what we already seen documented upon by other organizations regarding evil tokens. And so that sort of alignment mixed with sort of the complexity and the feature set of this platform made it incredibly interesting.

Amy Ciminnisi 2:59

So what exactly differentiates it from evil tokens? Is it the fact that it has all of these features that guide people through, you know, maintaining persistence, all the lords and everything? Is that the difference?

Michael Kelley 3:12

It's it's there's like layers. You know, the the intelligence published on evil tokens, what it showed a lot of researchers and you know, people trying to secure their environments was that there's a new mechanism that actually uses MFA to administer these tokens to the attacker. That was the initial sort of overlap, was both its approach of going after the primary refresh tokens, but and and how we sort of confirmed the affiliation was the actual, and we deobfuscated sort of the JavaScript embedded in some of this phishing infrastructure. The code itself was one-to-one on a lot of levels. So we knew there was there was an overlap there. Um, but what differentiates it is the built-upon features that are in the platform, whereas Evil Tokens was more inbox-centric, right? What you expect from a classic BEC. In this case, it was here's all the other things you can do with that PRT, right? Here's how you can interact with the victim's SharePoint, the OneDrive. Um, it offered features like keywords uh search or keyword monitoring, right? So that would become very useful in fraud, right? Because if you get access to a victim's email, the first thing you want to know is what are their vendor relationships? And you could sort of have passive monitoring on keywords so that from the attacker perspective, they're getting alerts or they're being able to enumerate certain emails that pertain to financial transactions so they can sort of craft personas and and you know begin to carry wire fraud out. So it's really the differential main differentiator is features in the platform that allow the attacker to do more with that PRT than than what we saw with evil tokens.

Amy Ciminnisi 4:50

Got it. Um, I I'd like to kind of get into two things that you've said there. First, let's talk more about the lure. One of the things that stood out was that like we often really see very generic spray and pray campaigns, but this one was very targeted. It was invoice, it was an invoice fraud attempt. So how are these attackers leveraging these, you know, vendor relationships to make them look so legit legitimate? Why does it make it hard for email filters to flag?

Michael Kelley 5:22

It's like what was in the blog. Um, that example was likely a byproduct of one side of that relationship already being compromised. It takes some some inside knowledge to know, hey, you know, this is a vendor of my target. This is what their telem or this uh their communications usually looks like from a format email and formatting perspective, et cetera. So in the highly targeted stuff, it's often likely, and we see this all the time. And as a someone that's been on IR, I've responded to cases like this where it's sort of hopping victim to victim and using the intelligence the attacker gains along the way to create a highly targeted lure. From a security perspective, what's interesting about this is that it's almost that, it's almost like the attacker, they're they're doing their best job to hide in plain sight as far as what's being sent to the victim. But the attacker knows that there's a chance that the email won't make it. And what I mean by that is when you look at the, and we see this commonly with phishing, like when you look at the header where the email is being sent from, you know, it's it's not uncommon to see effectively where the it says the email is coming from not aligning when you actually look at the header of where it actually came from. And there's email security for that, right? We have DMARC, and DMARC's there to say, hey, I know you're saying that you're sending it from here, but you're not, right? And so the attacker, I would assume, knows that there's a chance that for certain victims, those email security tools are turned on. But sometimes having them turned on is not enough, right? DMARC for a lot of email security platforms, DMARC is one of many attributes that these platforms are looking at to sort of risk score emails. And so there's cases where simply it failing DMARC might might not be enough. There's cases where maybe email security tools are maybe more in audit mode where it's flagged but it's still delivered. Um, and then there's cases, and I've seen this even today, where DMARC is just flat out not being used. Um, and so that's your first line of defense in cases like this, uh, where they're you know doing that impersonation, you can almost guarantee that where it to the user on the UI side where it says it's coming from is not. On top of that, if they get past that point, what they're doing that's interesting, that's sort of dissimilar to things I've seen in the past, is that they're actually creating SharePoint tenants. So if they are trying to impersonate a certain vendor, ultimately what they're trying to do, like many phishing attempts, is get them to click a link or a series of links. And so they're actually registering a SharePoint tenant, almost typosquatting the vendor they're impersonating. And then much like where the email is being appears to be sent from, that link is appearing to be a legitimate link to the actual vendor SharePoint tenant. But if you were to hover your cursor and actually uh look at the URL or sandbox it, you would see that that's not actually where it's going. It's going to sort of a typo squatted SharePoint. Um, and once clicked upon, that's taking them to that Cloudflare um infrastructure that is talked about the blog that is spun up sort of on demand by the platform to get them ultimately to uh perform MFA so that the attacker can get that device code.

Amy Ciminnisi 8:44

Got it. Yeah, so you kind of answered my next question. So um let's talk about the uh second point then. So it's it's one thing for an attacker to get into account an account, but the real goal for them is to stay there. Um, we talk about the primary refresh refresh token in the blog and persistence through that. Um, what does this mean for, you know, defenders who think that they've like mitigated an incident by like forcing a password reset? Like, you know, can can you walk us through this a little bit?

Michael Kelley 9:18

When I was first researching this, the thing that clicked for me, um, because being on the team that I'm on, we're researching everything under the sun. And so Bisemo Compromise is one of many, you know, I guess, sort of areas of focus for us. And so when I was first researching primary refresh tokens, the way that I on it clicked in my brain was that, okay, this is very similar to say you uh go buy a smart TV or you have sort of an IoT device that is keyboardless. Um, right. If you throw a new app on that smart TV and say you have your streaming subscription that you like to use, most of the time when you go to login, it's gonna give you a QR code and a device code, right? And once you scan that QR code, you're gonna be taken to an authentication page that's gonna take that device code and then effectively authenticate. The byproduct of that authentication is associating that device with a both authentication token and a refresh token. And so that is almost one-for-one what's what's happening in this case. So Microsoft has a uh device authorization grant, authentication flow that's for the same exact purpose. And so the attacker has the device code and they're tricking the uh victim to do the authentication so that they have effectively device level authentication. So where that's different and why password resets don't work alone is that the authentication session that the attacker has is not necessarily tied to the identity piece. It's tied to the device the attacker's on. And through tricking the user into MFA, they're not only authenticating the account, they're authenticating the device, which is meant much like you don't have to re-log in every time you want to use a streaming app, it's the same on the attacker side. This is a long-lived credential. And so a password reset isn't enough to de-authenticate, if you will, the attacker's device itself. Um, you actually would have to go into your O365 sort of admin admin panel and revoke it sort of manually from that device. If you know, if you've ever gotten an alert for any email or whatever saying, hey, this device authenticated, or you can go into your settings and you can see the devices that have authenticated using your credentials. It's not uh dissimilar to that.

Amy Ciminnisi 11:41

That makes sense. So for the defenders who are sitting here and listening to this and being like, okay, this is scary. What do I look for? Um, you know, what are the must-haves for detection? So, like if we can't count on MFA or just resetting passwords, what should we be hunting for to catch this before, you know, if if they start like exfiltrating data or things like that?

Michael Kelley 12:05

Well, I know Microsoft has a very, very vast uh API when it comes to interacting with all of the data that's a byproduct of you know everything you get within a Microsoft license. Um, and so you know, the things that you want to be looking for are device code activity. You want to be able to find events of devices specifically attempting to authenticate and get these tokens from you know from your Azure AD. For the most part, in an enterprise, the the enterprise itself is provisioning laptops to its users. And in most cases, those laptops have keyboards. And so one of the alerts you know you could be looking for is devices authenticating within your environment that don't match the make and model of the majority of laptops or devices that are being provisioned to your users. And and in another sense, ultimately you shouldn't see user accounts performing this kind of activity. It should be, you know, if if your office has smart TVs in it or IoT devices like thermostats, et cetera, you know, in a in a perfect world, those are tied to more purpose-built accounts that don't have inboxes. And so it would be common to see this kind of activity for those accounts. And from a threat hunt perspective, it would be very odd to see this sort of authentication from a user account that's you know on a uh just a normal, you know, laptop. So I would start there, looking at the accessible data that you have within your Microsoft APIs to track device authorization grant activity.

Amy Ciminnisi 13:41

Kind of stepping back and looking at the bigger picture, it feels to me like these platforms are becoming more and more sophisticated. Um, I don't know whether or not you agree with that. But, you know, with the integrated cloudflare management and, you know, those automated business email compromise pipelines, where do you see this phishing as a service model going? And how do people need to shift their defensive strategy in order to, you know, keep up with all of this automation?

Michael Kelley 14:15

Yeah, it's a fantastic question. I think as far as where it's going, you know, I think AI, here comes the AI word. AI has really recontextualized what is in the realm of possible for any given human being in any given role. Uh AI has made it really easy to fill in knowledge gaps and skill gaps very quickly. Um, and so I think what we can expect is panels similar to our token and evil token being increasingly common. You know, I think the intelligence now being out there, you know, the proof of concept being out there, it's obvious from an attacker perspective that you're gonna go the route where you're getting the most bang for your buck. You know, we see that all the time with ransomware. We've seen that with ransomware out change. It used to be dual time for ransomware attacks was months. And now ransomware has pivoted in such a way where they're able to carry out attacks in a matter of weeks because they're doing this at scale. And so the same with phishing, you know, you're gonna see things more tailored to how can I cast the widest net and get the best results. And so these platforms and having integrations with third parties make make that incredibly easier because now it's not a matter of hands-on keyboard, it's a matter of clicks. And so, from an AI perspective, I could see attackers continuing to research what is in the realm of possible. I have a primary refresh token. What can I do with that? That's you know, we saw how quickly things went from evil tokens to our tokens, where it went past the inbox level all the way into, oh, I can access SharePoint OneDrive, you know, et cetera, et cetera, et cetera. I think, and it's long-lived and survives past your resets. I see these panels, the the features being continued to be layered on and attackers researching and evolving to figure out, like I said, what what is in the realm of possible? What else can I touch with this? Can I touch, you know, um Power BI? Can I touch, you know, anything you would expect to see within the sort of Microsoft O through 65 app space and figuring out, okay, I I can access this. How does this play into the economics of what I'm trying to do? And so from a defender perspective, that's the mindset I would have, you know, of okay, now this is there's a precedent set. You know, I know what they're currently doing, but being able to sort of prepare for what might to come, and and what I think that is is nothing is safe effectively when it comes to being able to authenticate like this and to it's not it's past email, it's Azure AD at this point, right? It's it's right completely past the the inbox level. So I see that. And like I said, with the AI, it's it's really made it to where anything's possible. As researchers continue to try to understand what else can be done, attackers are doing the same.

Amy Ciminnisi 17:01

Yeah, thank you. Thank and thanks so much for joining, Michael. Do you have any other you know, parting words of advice for our listeners, for our defenders?

Michael Kelley 17:10

I mean, the only thing that comes to mind is as a researcher, ultimately I hope that the research that we publish is of use and um impacts not only our customers, but anyone reading it and helps them better secure their environments.

Amy Ciminnisi 17:22

Yeah, absolutely. For our listeners, I will put Michael's blog post in the show notes. You can always find our latest research on blog.talosintelligence.com. And there you can also subscribe to the Threat Source newsletter, which should hit your inbox every Thursday. Um, we have that come out with a fun editorial from our team, the week's headlines, where you can find us at conferences, and much more. Thanks for listening, everyone, and we'll be back in two weeks with another episode. Until then, stay safe out there.