Phish like an APT

Tunned Entra ID, hardened MFA and disabled device code auth. How to Phish now ?

The Evolution of Phishing

Traditional phishing attacks typically followed a predictable sequence: obtain user credentials, gain code execution, extract credentials from LSASS, move laterally across the network, and exfiltrate data while attempting to evade endpoint security controls.

This model has shifted significantly. With many organizations now operating in Entra ID, a single compromised cloud authentication token such as a Primary Refresh Token or an active session cookie can immediately provide broad access without requiring any of the traditional post‑exploitation steps.

• remote control

• exfiltration becomes an API call

• lateral movement turns into role enumeration

• persistence hides in OAuth apps

Modern attacks increasingly bypass traditional malware‑based techniques altogether. Instead of compromising endpoints, adversaries focus directly on identity‑based weaknesses. With the right stolen token, an attacker can operate entirely within legitimate cloud sessions, avoiding endpoint controls and leaving minimal forensic evidence.

This section provides an overview of how contemporary red teams leverage large‑scale phishing to exploit identity systems rather than devices, highlighting the shift toward credential and token‑centric attack paths.

Conditional Access Policy + Enforced MFA

To bypass the organization’s configured Entra ID controls, including multi‑factor authentication and Conditional Access Policies, the assessment used a crafted Intune enrollment link that took advantage of a misconfiguration in how device trust was being propagated. When the target user accessed this link, it initiated an OAuth 2.0 implicit flow that ultimately issued a refresh token, allowing continued authenticated access without requiring additional user interaction.

Technical Notes:

• The Intune flaw abuses insufficient scope validation, allowing token issuance without CAP prompts.

• Evilginx Phishlet (opsec.yaml) proxies the OAuth dance, capturing the refresh_token and session cookies.

TokenSmith, an open‑source tool developed by Jumpsec Labs, was used during the assessment to demonstrate how Conditional Access Policies can be bypassed under specific circumstances. By leveraging a misconfiguration related to Microsoft Intune exceptions, the tool was able to generate a crafted login URL that initiated an authentication flow outside the expected policy controls.

This URL will be embedded into the opsec.yaml configuration file used by the Evilginx phishlet.

Evilginx automatically retrieves a valid SSL certificate from Let’s Encrypt using the ACME protocol and then establishes a transparent reverse‑proxy connection between login.microsoftonline.com and the user’s browser. Operating in this man‑in‑the‑middle position enables the platform to capture session cookies and OAuth tokens while preserving end‑to‑end TLS encryption, making the activity difficult for users or security controls to detect.

The target user proceeds through the multi‑factor authentication prompt exactly as they would during a legitimate Microsoft sign‑in process.

As the user proceeds through the authentication process, their credentials are captured and displayed within the Evilginx console. After the user successfully completes the MFA challenge, the resulting session cookie is written to the local Evilginx log file, providing the attacker with a fully authenticated session.

The captured session cookie is then imported into a browser using a cookie‑management extension such as Cookie Editor. Once applied, the browser assumes the authenticated state of the victim, allowing full access to Microsoft services without requiring credentials or MFA.

At this stage, the attacker has already authenticated using the compromised user session. The next step is to request Microsoft Graph tokens—specifically the access and refresh tokens—which provide programmatic access to the user’s cloud resources and enable persistent interaction with Microsoft services.

Microsoft Graph Tokens

Microsoft Graph tokens can be obtained by using the custom link defined in the opsec.yaml phishlet. While still operating within the compromised browser session, the attacker can navigate to the Intune enrollment link, which triggers the issuance of both a refresh token and an access token.

The TokenTacticV2 toolkit is then used to interact with Entra ID APIs and refresh the obtained tokens, enabling continued authenticated access without requiring user involvement.

PS >Get-AzureTokenFromAuthorizationCode -Client MSGraph -RequestURL $FullRequestURL -Verbose -UseCAE

PS >RefreshTo-GraphToken -RefreshToken $response.refresh_token -ClientID 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223 -UseCAE -Domain target.domain

Primary Refresh Token

The Primary Refresh Token (PRT) is inherently linked to a device’s identity within Entra ID, and by default, standard users are permitted to register devices in the tenant. By taking advantage of this configuration, a rogue device—such as one labeled “purplePRT”—can be registered to the environment, allowing the attacker to associate a fraudulent device identity with the compromised account.

Because the target account is protected by MFA, the token request must explicitly include an MFA claim. This ensures that the issued Primary Refresh Token contains an embedded MFA assertion, allowing it to satisfy Conditional Access requirements that mandate strong authentication.

Once the user approves the MFA prompt, the resulting Primary Refresh Token is saved to a file (roadtx.prt). As long as the associated rogue device remains registered within the target tenant, this PRT can be used to obtain new access tokens and interact with Microsoft services under the user’s identity.

The stolen PRT is then used to authenticate a new browser session under the identity of the compromised user. Once this session is established, it provides seamless access to Microsoft services—including Outlook, Teams, OneDrive, and SharePoint—without prompting for credentials or MFA. In effect, the attacker can impersonate the user for as long as the token remains valid and the associated device is trusted by the tenant.

Recommendations

Enforce Conditional Access for Intune Enrollment

Implement the following Conditional Access configuration to ensure only trusted devices can obtain tokens: Entra ID → Conditional Access → Policies → Intune Device Enrollment → Set “Require device to be marked as compliant.”

This control ensures that only devices meeting your Intune compliance standards are permitted to authenticate, preventing attackers from registering rogue devices or leveraging misconfigurations in device trust propagation.

Conclusion

This assessment demonstrated how a combination of misconfigurations in Entra ID, Intune device enrollment, and Conditional Access enforcement can be chained together to bypass MFA protections and obtain long‑lived authentication artifacts such as session cookies, OAuth tokens, and ultimately a Primary Refresh Token (PRT). By leveraging tools like Evilginx, TokenSmith, and TokenTacticV2, an attacker can impersonate a legitimate user, register a rogue device, and maintain persistent access to Microsoft cloud services without further user interaction.

These findings highlight the critical importance of enforcing strict device compliance requirements, validating Conditional Access coverage, and ensuring that Intune enrollment exceptions cannot be abused to obtain trusted tokens. Strengthening these controls significantly reduces the attack surface and prevents adversaries from exploiting device trust propagation to gain privileged, persistent access.