ITInnovationStation

For years, organizations have been warned that phishing attacks are becoming more convincing. Employees are trained to examine links, question unexpected login pages and reject suspicious multifactor authentication requests. Security teams deploy email filtering, endpoint protection and conditional-access policies. Yet the modern threat to Microsoft 365 is no longer limited to a criminal building a fake login page and hoping someone enters a password.

ARToken represents the next stage of cloud-focused cybercrime: a platform designed to support much of the Microsoft 365 attack lifecycle from one centralized interface.

Cisco Talos disclosed ARToken in July 2026 after analyzing a publicly accessible portion of its operator panel. The researchers identified more than 80 API endpoints supporting functions such as device-code phishing, token collection, email access, Primary Refresh Token persistence, business email compromise operations and SharePoint data theft. Talos also found technical and operational connections between ARToken and the previously documented EvilTokens phishing-as-a-service ecosystem.

Calling ARToken a phishing kit is therefore technically accurate but strategically incomplete. It is better understood as a Microsoft 365 intrusion platform—a system that helps criminals obtain cloud identities, maintain access, inspect communications, steal information and monetize compromised organizations.

That distinction matters because many traditional defenses and incident-response procedures are still built around password theft. ARToken illustrates why defenders must now think in terms of token theft, cloud persistence, application access and identity-based post-compromise activity.

From phishing page to criminal cloud platform

A conventional phishing kit usually provides several basic components: a replica login page, a mechanism for collecting credentials and perhaps a dashboard where the attacker can view stolen usernames and passwords.

ARToken goes much further.

The exposed platform appears to provide its operators with an integrated environment for conducting attacks against Microsoft 365 users. Rather than forcing criminals to assemble separate tools for phishing, mailbox access, token management, persistence and data theft, ARToken brings those capabilities together through a React-based web dashboard and a substantial backend API.

This is an important evolution in the cybercrime economy. Complexity that once required a technically capable operator can now be packaged into a commercial service. The affiliate using the service may not need to understand the Microsoft identity platform in depth. The platform can abstract many of the technical steps behind buttons, forms and automated workflows.

This is the same industrialization process previously seen with ransomware-as-a-service. Ransomware affiliates do not necessarily write encryption software, develop payment portals or operate leak sites. Those services are provided by the platform operator. The affiliate concentrates on obtaining access and selecting victims.

ARToken applies a similar model to Microsoft 365 compromise.

A criminal can potentially move from initial deception to authenticated cloud access, mailbox surveillance, document discovery and business email compromise without developing a custom toolchain. That lowers the barrier to entry and allows successful attack methods to be reproduced across a much larger number of targets.

Device-code phishing changes the nature of the login attack

One of ARToken’s central capabilities is device-code phishing.

The legitimate Microsoft device authorization flow exists for devices or applications where entering credentials directly may be impractical. A user is shown a temporary code and instructed to visit a Microsoft authentication page. After entering the code and completing authentication, the requesting application receives authorization.

Attackers abuse this process by initiating the authorization request themselves and convincing the victim to enter the attacker-generated code.

The victim may interact with a genuine Microsoft website rather than an obvious counterfeit login page. The browser address, certificate and Microsoft branding can all appear legitimate because the user really is authenticating through Microsoft.

The deception lies in what the user is authorizing.

A victim might receive an email, Teams message or fake support request claiming that a document, voicemail, shared file or security verification requires a Microsoft code. When the victim enters the code and completes authentication, the resulting token can be delivered to the attacker-controlled session.

This can weaken one of the most common pieces of anti-phishing advice: “Check that you are signing in on the real Microsoft website.” With device-code phishing, the Microsoft page may be real. The authorization request is the malicious component.

Multifactor authentication does not necessarily prevent this attack. The victim may complete MFA as part of the legitimate authentication process, unintentionally granting the attacker an authenticated token afterward. The attacker is not always bypassing MFA through a technical exploit; the attacker is manipulating the user into completing it for the wrong session.

This is why organizations must move beyond treating MFA as a universal cure for account compromise. MFA remains essential, but authentication strength must be combined with controls over devices, applications, token issuance, session risk and authorization behavior.

Tokens are becoming more valuable than passwords

A password is a secret used to request access. An authentication token is evidence that access has already been granted.

That difference makes tokens particularly valuable to attackers.

When a criminal steals a password, the criminal may still encounter MFA, conditional-access restrictions, unfamiliar-location alerts or other authentication barriers. A usable token may allow the criminal to operate inside an already authenticated context until the token expires, is revoked or is rejected by another security control.

ARToken’s design reflects this shift in attacker priorities. It is not merely interested in recording usernames and passwords. Its capabilities center on collecting and operationalizing Microsoft 365 authentication tokens.

This is part of a wider transition from credential theft to session theft. Adversary-in-the-middle phishing systems, malicious browser extensions, information stealers and token-focused phishing services all seek to capture the authenticated state rather than repeatedly authenticate with the victim’s password.

For defenders, the distinction has major consequences.

Resetting a compromised password is important, but it may not immediately invalidate every active session or remove every persistence mechanism. A cloud-account investigation must also consider refresh tokens, session cookies, registered authentication methods, joined or registered devices, OAuth grants, enterprise applications and other objects that can preserve or restore access.

An organization that responds to a modern token compromise with only a password reset may leave the intruder connected.

The threat of Primary Refresh Token persistence

Among the most concerning functions associated with ARToken is support for Primary Refresh Token, or PRT, persistence.

A PRT is an important component of Microsoft Entra ID authentication on registered or joined Windows devices. It helps provide single sign-on to Microsoft applications and services. Because of its privileged role in the authentication experience, access associated with a PRT can be particularly valuable to an attacker.

Talos reported that the ARToken panel includes functionality associated with PRT persistence, indicating an interest in converting an initial compromise into more durable access.

The exact success of such activity depends on the environment, device state, Microsoft controls and the attacker’s level of access. The presence of the functionality is nevertheless significant. It demonstrates that the platform’s developers are not satisfied with a short-lived mailbox session. They are building workflows around persistence within the Microsoft identity ecosystem.

This changes how an incident should be scoped.

Security teams cannot assume that the affected object is only a user account. The investigation may need to include Entra device registrations, Windows sign-in artifacts, authentication methods, token issuance, application consent and device-compliance history.

The identity, device and cloud application must be treated as one connected security boundary.

Business email compromise as a built-in workflow

Business email compromise has traditionally been described as the final outcome of an email account takeover. An attacker gains access, reads messages, identifies a financial opportunity and impersonates the user.

ARToken appears to make those post-compromise activities part of the platform itself.

Talos identified capabilities for accessing email, viewing messages, sending mail, manipulating mailbox content and supporting BEC operations. The platform also contains functionality related to SharePoint and other Microsoft 365 resources.

This is why some security reporting has characterized ARToken as closer to “BEC-as-a-service” than a normal phishing kit.

Once an attacker controls a mailbox, the criminal can study the organization from inside. Email provides names, roles, signatures, writing styles, suppliers, customers, projects and payment processes. A patient attacker can observe a legitimate financial conversation and intervene at exactly the right moment.

The attacker may register a look-alike domain, alter a reply-to address or simply send from the compromised mailbox. Payment instructions can be changed while preserving the tone and context of the original conversation.

This form of fraud is dangerous because the malicious message may not contain malware, an exploit or even a suspicious link. It may be a plain-text reply inside an authentic conversation from a genuine account.

Technology designed only to identify malicious attachments and fake sender domains can miss the most important phase of the attack.

Defending against BEC therefore requires financial-process controls as well as cybersecurity controls. Changes to bank accounts, wire instructions, payroll destinations or payment details should require an independent verification method. A reply within the same email thread is not sufficient verification when the mailbox itself may be compromised.

SharePoint and OneDrive expand the damage

A Microsoft 365 identity is not merely an email account.

Depending on the user’s role and permissions, the same identity may provide access to SharePoint sites, OneDrive files, Teams conversations, customer information, contracts, internal procedures and confidential business records.

ARToken’s SharePoint-related capabilities show that its developers understand the value of this broader environment.

After compromising a user, an attacker can use the victim’s legitimate access to search for useful material. The attacker may discover invoices, banking documents, executive correspondence, insurance records, password spreadsheets, technical diagrams or client information.

This access may not trigger endpoint malware alerts because the criminal is interacting with cloud services through valid APIs and authenticated sessions. To Microsoft 365, many of the individual actions may resemble ordinary user activity.

The challenge is identifying when normal capabilities are being exercised in an abnormal context.

Security teams need visibility into unusual SharePoint downloads, bulk file access, new sharing links, abnormal search activity and access originating from unfamiliar infrastructure. They must also understand each user’s normal cloud behavior well enough to distinguish an accountant downloading a monthly report from an intruder enumerating an entire site.

Why endpoint protection alone cannot solve this problem

ARToken demonstrates the limits of an endpoint-only security strategy.

An attacker may successfully compromise a Microsoft 365 identity without installing malware on the user’s computer. The victim can be deceived on a personal phone, unmanaged browser or remote system. The attacker can then operate against Microsoft’s cloud services from infrastructure the organization has never seen.

An endpoint detection and response product installed on the employee’s workstation may have little or no visibility into those actions.

This does not make endpoint security irrelevant. Information stealers, malicious browser activity and token theft can still involve endpoints. But the identity platform itself must be monitored as a primary security environment.

Organizations need to collect and analyze Entra sign-in logs, non-interactive authentication, audit activity, mailbox operations, application consent, inbox-rule changes, forwarding configurations, SharePoint access and device registrations.

Cloud telemetry is no longer supplemental evidence. In an identity-driven intrusion, it may be the principal evidence.

What organizations should do now

The first priority is to review device-code authentication.

Organizations that do not require the device-code flow should consider blocking or tightly restricting it through Microsoft Entra Conditional Access and authentication policies. Where it remains necessary, its use should be limited to approved users, applications, devices and operational scenarios.

Phishing-resistant authentication should also be prioritized. FIDO2 security keys, Windows Hello for Business and certificate-based authentication provide stronger resistance to many common phishing techniques than passwords combined with push notifications.

Conditional Access should evaluate more than whether MFA occurred. Policies should consider device compliance, managed-device status, sign-in risk, location, application sensitivity and authentication strength.

Organizations should monitor for:

• Unexpected device-code authentication.
• Sign-ins from unfamiliar infrastructure.
• New or suspicious device registrations.
• Unusual refresh-token activity.
• New inbox forwarding rules.
• Changes to mailbox delegates.
• New OAuth grants or application consent.
• Suspicious SharePoint and OneDrive downloads.
• Authentication-method changes.
• Abnormal access following a successful phishing event.

Financial departments need procedural safeguards. Any request to change payment instructions should be confirmed using a trusted phone number or separate communication channel. The verification process must not rely on contact information supplied in the potentially compromised email.

Users should also receive specific training about device-code phishing. Generic warnings about fake login pages are not enough. Employees should understand that a genuine Microsoft page can still be part of an attack and that they should never enter a device code unless they personally initiated a known device or application setup.

Responding to a suspected ARToken-style compromise

A proper response must extend beyond changing the password.

The organization should disable or contain the account, revoke active sessions and refresh tokens, reset authentication credentials and review recently registered MFA methods. Investigators should examine Entra sign-ins, device registrations, OAuth consent, enterprise applications, mailbox rules, forwarding addresses, delegates, sent messages, deleted messages and SharePoint activity.

The user’s managed endpoints should also be checked for information stealers, browser-session theft or other compromise. Financial transactions associated with the affected mailbox should be reviewed immediately.

Investigators should determine whether the attacker used the account to target additional employees, customers or vendors. A compromised mailbox frequently becomes the launch point for the next stage of the campaign.

Where sensitive files were accessed, the event may need to be treated as a data breach rather than merely an account compromise.

The larger warning behind ARToken

The most important lesson from ARToken is not the name of the platform or the number of functions exposed in its API.

The larger issue is the industrialization of cloud-account compromise.

Attackers are converting sophisticated identity attacks into repeatable commercial services. They are packaging phishing, token theft, persistence, mailbox access, document theft and fraud into interfaces that can be used by affiliates with varying levels of technical skill.

That development will increase both the number and quality of attacks against Microsoft 365 environments.

Organizations must stop treating cloud identity as a supporting component of security. For many businesses, Microsoft 365 is the primary operating environment. It contains the organization’s communications, documents, identities and business relationships.

Compromising that environment can provide everything an attacker needs without deploying traditional malware or breaching an on-premises server.

ARToken is therefore not simply another phishing kit. It is evidence that business email compromise and cloud intrusion are becoming platformized industries.

The appropriate defensive response is equally significant: phishing-resistant authentication, strict control of device-code flows, comprehensive cloud logging, rapid token revocation, identity-focused incident response and business processes that assume even a legitimate mailbox can become hostile.

The password is no longer the only key attackers want.

Increasingly, they want the authenticated identity itself.