ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365
Cisco Talos identified ARToken, a phishing-as-a-service platform linked to EvilTokens, that abuses Microsoft's OAuth 2.0 Device Authorization Grant to bypass MFA and capture victim tokens. The platform provides affiliates with a comprehensive post-compromise toolkit including PRT-based persistence surviving password resets, BEC email operations, inbox rule manipulation, and SharePoint exfiltration. ARToken deploys a sophisticated seven-layer client-side anti-analysis system and abuses legitimate sharepoint.com URLs from attacker-controlled Microsoft 365 workspaces to evade security scanners.
- domainclear90489058903-document[.]workers[.]devCloudflare Workers domain used for deploying ARToken phishing lure pages to victims
- domaindashboard-bl[.]pamconj[.]comARToken affiliate management panel hosting React-based SPA dashboard for operators to manage captured tokens, BEC operations, and phishing deployments
- domainspx[.]pamconj[.]comARToken C2 API server handling device code phishing initiation, PRT lifecycle management, and token operations via 80+ API endpoints
- filenamepumber.pngInline signature image embedded in phishing emails as part of light per-message mutation to frustrate exact-match content rules
- urlhxxps://mononapfpcom[.]sharepoint[.]com/:f:/g/IgAdH_aaBPMcQbtINZzC1TsLARj3dHj63MnKjvnY-QJrKEcAttacker-controlled Microsoft 365 SharePoint tenant URL used as phishing destination; designed to look like legitimate vendor SharePoint while inheriting sharepoint.com's clean reputation
- urlhxxps://mononapfp[.]sharepoint[.]com/:f:/document/INV-IgCx1X50pgUjR7iAjZL2fuQaAW4GfKVs6wHT3BYv9sgwW7gSpoofed SharePoint anchor text displayed in phishing email visible link; impersonates legitimate vendor tenant mononapfp.com
Detection / Hunteropenrouter
What Happened
A criminal service called ARToken lets attackers steal login credentials from Microsoft 365 users by tricking them into entering a device code on Microsoft's own login page, which completely bypasses multi-factor authentication (the extra security step like a text message code). Once inside, attackers can read and send emails as the victim, create hidden inbox rules to cover their tracks, access SharePoint and OneDrive files, and maintain access even if the victim changes their password. The phishing emails impersonate real vendors with fake invoice notices and use genuine Microsoft SharePoint links to avoid detection. Organizations using Microsoft 365 — especially finance, HR, and logistics teams — are the primary targets. This matters because the platform is sold as a subscription service to multiple criminal groups, scaling the threat widely. Defenders should educate staff about device code phishing, monitor for unusual inbox rules and token activity, and verify that email authentication (SPF, DKIM, DMARC) is properly enforced.
Key Takeaways
- ARToken is a fully-featured phishing-as-a-service platform linked to EvilTokens, sharing identical API contracts, PRT lifecycle endpoints, and Cloudflare Workers deployment patterns.
- The platform bypasses MFA entirely by abusing Microsoft's OAuth 2.0 Device Authorization Grant (RFC 8628), then escalates to Primary Refresh Token (PRT) persistence that survives password resets.
- A seven-layer client-side anti-analysis system (User-Agent regex, webdriver checks, fingerprinting, interaction telemetry, timing gates, movement pattern analysis) exceeds prior EvilTokens evasion capabilities.
- Post-compromise toolkit includes full Outlook inbox access, BEC email sending with BCC batching, inbox rule manipulation for evidence suppression, SharePoint/OneDrive file operations, and cross-account keyword monitoring.
- Phishing lures abuse genuine sharepoint.com URLs from attacker-controlled Microsoft 365 workspaces, inheriting SharePoint's clean reputation to evade URL scanners.
Affected Systems
- Microsoft 365 (Exchange Online, SharePoint Online, OneDrive)
- Microsoft Azure AD / Entra ID authentication infrastructure
- Windows endpoints (ARTBrowser standalone application)
- Cloudflare Workers (abused for phishing lure deployment)
Attack Chain
Attackers send targeted vendor-impersonation invoice phishing emails to accounts-payable staff, with Reply-To redirected to attacker-controlled domains and visible SharePoint anchor text linking to attacker-controlled Microsoft 365 workspace tenants on genuine sharepoint.com. The phishing page deploys a seven-layer anti-analysis system requiring organic mouse movement, timing gates, and browser fingerprinting before delivering an XOR-encrypted payload that calls the C2 at /device/start with a hardcoded operator UUID. The victim is presented with a device code and directed to microsoft.com/devicelogin; upon completion, the captured token appears in the ARToken dashboard where operators can refresh tokens, escalate to PRT via /prt/setup → /prt/refresh → /prt/cookie for password-reset-surviving persistence, read and send emails as the victim with BCC batching and auto-deleting inbox rules, and exfiltrate SharePoint and OneDrive files.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Cisco Talos GitHub IOC repository (linked but not embedded in article)
The article references a GitHub repository containing IOCs but does not embed any detection rules, queries, or signatures in the article text itself.
Detection Engineering Assessment
EDR Visibility: Low — The attack primarily operates through cloud-based phishing and Microsoft 365 API abuse; endpoint telemetry is limited to the optional ARTBrowser Windows application and victim browser activity. Device code phishing occurs in the browser and Microsoft's authentication flow, which may not generate EDR-relevant process telemetry. Network Visibility: Medium — C2 communications to spx.pamconj.com and phishing lure traffic to Cloudflare Workers domains are visible at the network layer. However, traffic to legitimate sharepoint.com and microsoft.com/devicelogin endpoints blends with normal business traffic and is difficult to distinguish without URL-level inspection. Detection Difficulty: Hard — The platform abuses legitimate Microsoft authentication flows and genuine sharepoint.com URLs, making network-based detection extremely difficult. Seven-layer anti-analysis evades automated scanners. PRT persistence survives password resets, and inbox rule manipulation suppresses evidence. Detection requires correlating across email, cloud identity, and mailbox audit log sources.
Required Log Sources
- Microsoft 365 audit logs (Exchange mailbox audit, Azure AD sign-in logs)
- Microsoft 365 Defender / Sentinel cloud-native logs
- Email gateway logs with SPF/DKIM/DMARC authentication results
- Web proxy / Secure Web Gateway logs with full URL inspection
- DNS resolution logs for pamconj.com and workers.dev domains
- Azure AD Conditional Access and token issuance logs
- Cloudflare Workers deployment logs (if Cloudflare is used in the environment)
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for device code authentication flows in Azure AD sign-in logs where the initiating context is a phishing page rather than a legitimate device enrollment, particularly looking for T1566.002 patterns followed by rapid token grant from unexpected IP addresses or geographies. | Azure AD sign-in logs, Conditional Access logs, Microsoft 365 audit logs | Initial Access / Credential Access | Medium — legitimate device code flows from IoT devices, CLI tools, and some legacy applications may generate similar patterns. |
| Consider hunting for newly created inbox rules that forward to external addresses or auto-delete messages containing keywords like 'invoice', 'payment', or 'phishing', especially if created shortly after a suspicious sign-in event. | Exchange mailbox audit logs (New-InboxRule operations), Microsoft 365 audit logs | Persistence / Collection | Medium — legitimate users sometimes create forwarding rules for personal email or auto-filing rules that may resemble evidence suppression. |
| Consider hunting for Primary Refresh Token acquisition events (T1098.001) following device code authentication, particularly tokens flagged as PRT-enabled or persisting across subsequent password reset events. | Azure AD token issuance logs, Microsoft 365 Defender identity protection alerts | Persistence | Low — PRT acquisition via device code flow is unusual in most enterprise environments and warrants investigation. |
| Consider hunting for DNS resolutions to pamconj.com or workers.dev subdomains with patterns matching {uuid}-docviewer, {uuid}-onedrive, or {uuid}-adobe2 naming conventions, which indicate ARToken phishing infrastructure. | DNS logs, web proxy logs, firewall logs | Initial Access / Resource Development | Low — these domain patterns are highly specific to ARToken/EvilTokens infrastructure. |
| Consider hunting for emails where the From domain differs from the Reply-To domain and SPF, DKIM, and DMARC all fail, particularly those containing SharePoint links to tenant names that embed a vendor's domain with .com folded into the tenant label. | Email gateway logs, Secure Email Gateway authentication results, message tracking logs | Initial Access | Medium — some legitimate bulk senders may fail authentication checks, but the combination of Reply-To pivot plus all-auth-failure plus SharePoint look-alike is highly suspicious. |
Control Gaps
- Email authentication (SPF/DKIM/DMARC) enforcement alone will not block this attack because phishing destinations use genuine sharepoint.com URLs with clean reputation.
- URL scanners and sandbox analysis are bypassed by the seven-layer client-side behavioral verification system requiring organic mouse movement and timing gates.
- MFA provides no protection against device code phishing since the OAuth Device Authorization Grant flow is designed to work without interactive browser prompts.
- Password resets do not remediate compromise when PRT persistence has been established via the /prt/setup chain.
- Standard DLP may not detect exfiltration through legitimate Microsoft 365 SharePoint and OneDrive APIs using stolen tokens.
Key Behavioral Indicators
- Emails with From domain differing from Reply-To domain, combined with SPF/DKIM/DMARC authentication failures
- SharePoint URLs where the tenant name embeds a vendor domain with .com folded into the label (e.g., mononapfpcom instead of mononapfp.com)
- Inbox rules created shortly after sign-in events from device code authentication flow
- JavaScript accessing localStorage key 'artoken_jwt' and making POST requests to /api/device/start with clientMode: 'broker'
- DNS queries to pamconj.com subdomains or Cloudflare Workers domains matching {uuid}-docviewer/{uuid}-onedrive/{uuid}-adobe2 patterns
- Azure AD device code grant events followed by PRT issuance and subsequent access from unexpected locations
False Positive Assessment
- Low — the identified IOCs (pamconj.com domains, specific Cloudflare Workers subdomain, SharePoint look-alike tenant URLs) are highly specific to ARToken infrastructure. Behavioral indicators such as device code flow followed by PRT acquisition and inbox rule creation have moderate false positive risk from legitimate administrative activity, but the combination of indicators significantly reduces false positive likelihood.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider searching email gateway logs and Microsoft 365 audit logs for any traffic to or from pamconj.com domains, the listed Cloudflare Workers domain, and the identified SharePoint look-alike URLs.
- If compromised mailboxes are identified, consider reviewing all inbox rules for forwarding or auto-deletion rules created in the relevant timeframe, and evaluate whether token revocation and forced re-enrollment of devices is warranted.
- Consider blocking the identified IOCs (pamconj.com, clear90489058903-document.workers.dev) at DNS resolution and web proxy layers if supported by your infrastructure.
- If PRT persistence is suspected, consider evaluating whether conditional access policies can require re-authentication for sensitive resources, and verify whether revoking all refresh tokens for affected accounts is appropriate.
Infrastructure Hardening
- Consider evaluating whether Conditional Access policies can restrict device code authentication flow (RFC 8628) to only approved applications or compliant devices, if supported by your Microsoft 365 licensing.
- Consider reviewing and tightening DMARC policy from p=none to p=quarantine or p=reject for your organization's domains to reduce spoofing risk against your brand.
- If your organization uses Cloudflare, consider reviewing Cloudflare Workers deployments for any unauthorized phishing pages matching the documented naming patterns.
- Evaluate whether Microsoft 365 alert policies for suspicious inbox rule creation and unusual sign-in patterns are enabled and routed to your monitoring team.
User Protection
- Consider deploying targeted phishing awareness training focused on device code phishing lures, emphasizing that Microsoft will never ask users to enter a code at microsoft.com/devicelogin from an email link.
- If supported by your email gateway, consider enabling enhanced scanning for emails where Reply-To differs from From and all authentication checks fail.
- Consider evaluating whether URL rewriting and time-of-click protection can inspect SharePoint links that redirect to different tenant names.
- Consider alerting finance, HR, and logistics teams specifically about vendor-impersonation invoice fraud patterns described in the article.
Security Awareness
- Consider incorporating device code phishing awareness into existing security awareness programs, explaining that entering codes at microsoft.com/devicelogin grants attackers full account access bypassing MFA.
- Consider training accounts-payable staff to verify vendor invoice communications through out-of-band channels (phone, known contact) before acting on outstanding-invoice queries.
- Consider educating users to inspect the actual href destination of SharePoint links in emails, not just the visible anchor text, and to report discrepancies.
- If applicable to your awareness program, consider highlighting that password changes alone may not remediate a compromise if attackers have established persistent token access.
MITRE ATT&CK Mapping
- T1566.002 - Phishing: Spearphishing Link
- T1528 - Steal Application Access Token
- T1098.001 - Account Manipulation: Additional Cloud Credentials
- T1114.002 - Email Collection: Remote Email Collection
- T1550.001 - Use Alternate Authentication Material: Application Access Token
- T1531 - Account Access Removal
- T1583.006 - Acquire Infrastructure: Web Services
- T1027 - Obfuscated Files or Information
- T1497.001 - Virtualization/Sandbox Evasion: System Checks
Additional IOCs
- Other:
84eb384d-cd3e-4c90-a283-c960ce557913- Hardcoded operator UUID embedded in phishing kit JavaScript; sent as userId parameter to /device/start C2 endpoint for victim session correlationartoken_jwt- localStorage key name used by ARToken phishing kit to store and retrieve victim JWT tokens for session correlation[233,69,224,219,53,48,213,165,119,243,77,151,101,148,15,227]- 16-byte XOR key used to encrypt/decrypt JavaScript phishing payload at runtime, replacing EvilTokens' documented AES-GCM encryptionPOST /api/device/start- Primary API endpoint for initiating device code phishing flow; accepts JSON body with userId, clientMode: broker, login_hint, and redirect_url/prt/setup- API endpoint initiating PRT acquisition chain for persistence surviving password resets/prt/refresh- API endpoint for refreshing Primary Refresh Tokens to maintain persistent access/prt/cookie- API endpoint for extracting PRT cookies enabling session persistence across password changes