Listen to this Post
Introduction:
In the ever-evolving landscape of cyber threats, Adversary-in-the-Middle (AitM) phishing frameworks have moved beyond simple credential theft. A recent development by security researcher Nathan McNulty demonstrates a sophisticated post-exploitation technique targeting Microsoft 365. By leveraging the ESTSAUTH cookie obtained during an AitM attack, an attacker can register a legitimate FIDO2 passkey to the victim’s account, effectively granting the attacker persistent authentication even if the victim changes their password. This article dissects the PowerShell implementation of this technique, exploring the attack chain, the critical time window for exploitation, and the defensive measures required to mitigate this novel persistence method.
Learning Objectives:
- Understand the role of the ESTSAUTH cookie in Microsoft 365 authentication and why it is a prime target for AitM frameworks.
- Analyze the PowerShell script that automates the registration of a passkey using a stolen session cookie.
- Identify the detection opportunities and security hardening measures (including Conditional Access and Key Trust policies) to defend against this attack.
You Should Know:
- Understanding the AitM Attack Chain and the ESTSAUTH Cookie
AitM phishing, often executed with tools like Evilginx2, operates by acting as a reverse proxy between the user and the legitimate login page (login.microsoftonline.com). When the victim submits their credentials and MFA, the proxy captures the session tokens.
One of the most valuable artifacts from a successful M365 authentication is the `ESTSAUTH` cookie. This is a persistent authentication token used by Microsoft services. Unlike an access token which might be short-lived, the ESTSAUTH cookie is often used for single sign-on (SSO) and can be valid for extended periods. In the context of this exploit, it is the key that allows the attacker to interact with the authenticated session as if they were the victim.
2. The Mechanics: Registering a Passkey via PowerShell
The core of this technique is a PowerShell script designed to take a stolen ESTSAUTH cookie and use it to enroll a new passkey. The process leverages the underlying REST APIs that the Microsoft Authentication Library (MSAL) and the browser use to manage security info.
Step-by-step guide (Conceptual Execution):
- Acquire the Cookie: The attacker must first obtain a valid `ESTSAUTH` cookie via an AitM phishing campaign.
- Prepare the Environment: The attacker runs PowerShell on a machine they control. They must have the necessary modules or be able to make raw HTTP requests.
- Execute the Script: The script uses the stolen cookie to authenticate to the Microsoft Graph API or the specific security info registration endpoint (`https://mysignins.microsoft.com`).
- Bypassing MFA: Because the session is already authenticated (via the cookie), the API trusts the request and allows the addition of a new authentication method—in this case, a FIDO2 security key (passkey).
- Persistence: The passkey is now a valid authentication method for the account. The attacker, possessing the private key associated with this passkey, can now sign in even if the victim resets their password.
3. The 5-Minute Window and Operational Security (OpSec)
A critical limitation highlighted in the original post is the existence of a short exploitation window—approximately 5 minutes. This window refers to the validity of the specific stolen session for performing sensitive operations like adding new security info. While the ESTSAUTH cookie itself might be valid for longer, the “credential management” session token derived from it may have a stricter time-to-live (TTL). This forces attackers to automate the process immediately upon cookie capture to ensure the operation succeeds.
4. Hardening Defenses: Key Trust and Conditional Access
To mitigate this type of attack, organizations must move beyond simple MFA and implement phishing-resistant authentication and strict policies.
– Implement Phishing-Resistant MFA: Move towards passkeys (FIDO2) for all users, but ensure they are enforced with Key Trust. In a hybrid environment, this means rolling over the public key to on-premises Active Directory via Azure AD Connect, ensuring the trust is rooted in the hardware key.
– Conditional Access (CA) Policies: Create CA policies that restrict the registration of security information based on location, device compliance, or known IP addresses.
– Example CA Rule: Block the registration of new authentication methods if the request originates from an IP address not marked as trusted or from a non-compliant device.
– Authentication Strength: Use Conditional Access to require a specific “Authentication Strength” (e.g., phishing-resistant MFA) for high-risk operations like updating security info.
– Monitor and Hunt:
– Audit Logs: In the Microsoft 365 Defender portal, monitor the `AuditLogs` for `Update user` activities, specifically targeting the `StrongAuthenticationRequirements` or `StrongAuthenticationMethods` attributes.
– KQL Query:
AuditLogs
| where OperationName == "Update user"
| where TargetResources has_any ("StrongAuthenticationRequirements", "StrongAuthenticationMethods")
| extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend IpAddress = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, InitiatedBy, IpAddress, TargetResources
5. Red Team Implementation (Linux/Windows Perspective)
While the original tool is PowerShell (Windows-centric), the concept is cross-platform. A Red Team operator could replicate this on Linux using tools like `curl` and Python.
1. Capture the Cookie: Use an AitM tool (e.g., Evilginx2) on a Linux VPS to phish the user and capture the `ESTSAUTH` cookie.
2. Replay the Session: Use `curl` to send a POST request to the Microsoft security info endpoint with the stolen cookie.
Example curl command structure (conceptual)
curl -X POST \
'https://mysignins.microsoft.com/api/User/SecurityInfo/Add' \
-H 'Content-Type: application/json' \
-H 'Cookie: ESTSAUTH=YOUR_STOLEN_COOKIE_VALUE;' \
-d '{
"MethodType": "passkey",
"DisplayName": "Corporate Hardware Key",
"PublicKey": "ATTACKER_GENERATED_PUBLIC_KEY"
}'
3. Key Generation: The attacker must generate a valid FIDO2 key pair locally, sending only the public key to Microsoft while retaining the private key for future authentication.
- Storing the Key Material: Azure Key Vault Integration
Nathan McNulty mentioned an unpublished script that stores the generated passkey in Azure Key Vault. This is an advanced OpSec maneuver. By storing the private key material in a cloud vault, the attacker avoids keeping persistent files on their operational machine.
– The Process:
1. The script creates a new passkey (public/private key pair).
2. It authenticates to Azure (using separate compromised credentials or managed identity).
3. It stores the private key as a secret in a pre-provisioned Azure Key Vault.
4. The public key is registered to the victim’s M365 account.
5. The attacker can later retrieve the private key from the vault to complete authentication, making the attack harder to trace back to a single machine.
What Undercode Say:
- Key Takeaway 1: Tokens are the new credentials. This attack highlights the paradigm shift from stealing passwords to stealing sessions. The ESTSAUTH cookie is as valuable as a password, and in some cases (like registering new MFA), it is more valuable. Security awareness must evolve to treat session cookies with the same sensitivity as credentials.
- Key Takeaway 2: Persistence is shifting to “Legitimate” Enrollment. Instead of creating backdoors in code, attackers are increasingly exploiting the “self-service” tools provided by identity providers. Registering a passkey is a legitimate administrative action; abusing it with a stolen token makes detection far more difficult.
This technique represents a maturation of post-exploitation tradecraft. It moves away from noisy, malware-based persistence and toward abusing the identity fabric itself. The use of the ESTSAUTH cookie to enroll a passkey effectively weaponizes the victim’s own security infrastructure against them. Defenders can no longer rely solely on password hygiene; they must implement strict Conditional Access policies that govern how, when, and where users can modify their own authentication methods. The introduction of Azure Key Vault for key storage further illustrates how attackers are leveraging cloud-native tools to cover their tracks, creating a persistent presence that is resilient to password resets and traditional EDR solutions.
Prediction:
We will see a rapid arms race in the identity space. As passkeys become the standard, attackers will pivot from stealing passwords to weaponizing the provisioning process for these keys. Expect to see AitM frameworks updated to automatically execute these post-exploitation scripts upon successful cookie capture, closing the 5-minute window into a near-instantaneous operation. Consequently, Microsoft and other IdPs will be forced to introduce “credential management sessions” that are entirely separate from primary authentication sessions, requiring step-up authentication even for users with a valid ESTSAUTH cookie when performing high-impact security changes.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
