Ra is a valuable Active Directory case study because nothing here is magic. The fictional domain falls through familiar trust failures: over-shared identity recovery data, a client-side authentication exposure, an operator role that does too much, and automation that evaluates data as code.
This is an original synthesis, not a collage of walkthroughs. I used the official room, NVD, and Microsoft documentation to verify the technical route. The writeup focuses on the reasoning between stages: what the evidence proves, when to stop, and what a defender should repair.
01 · The attack model
The room starts on WindCorp's internal network and ends with three flags. The transferable lesson is the chain of trust: public portal clue → one reset flow → a readable SMB share → an exposed chat-client behaviour → delegated identity administration → a privileged task that trusts lower-privilege input. A good assessment narrows uncertainty at every step instead of jumping straight to a payload.
02 · Reconnaissance: identify the control plane
Start with a service inventory against the IP assigned to the active room. Keep that address as a variable so commands remain readable, and save the output for later correlation.
export TARGET_IP="10.10.X.X"; nmap -sC -sV -Pn -oA nmap/ra "$TARGET_IP"Representative output includes DNS, HTTP, Kerberos, LDAP, SMB, and WinRM. Together, those services are a strong Active Directory signal. Record the domain and host names shown by the lab only, then map them locally if the application requires names. Do not guess credentials or spray services.
53/tcp domain · 80/tcp http · 88/tcp kerberos · 389/tcp ldap · 445/tcp smb · 5985/tcp wsman03 · Portal metadata is still identity data
The WindCorp page exposes employee information and a password-reset route. Read the page, linked image names, and reset questions before opening a large wordlist. The key clue is not a password. It is an image filename joining an employee account to a pet name. In a real organisation, that is an identity-recovery design defect: a supposedly private answer has been published as asset metadata.
curl -s "http://$TARGET_IP/" -o web-index.html; curl -s "http://$TARGET_IP/" | grep -niE 'reset|employee|img|support'The reset flow validates the clue and returns a lab credential. Keep it private. It is an input to the next authorised boundary, not something to reproduce in public.
Knowledge-based questions about pets, schools, family, or vehicles are weak because those facts accumulate in public and internal material. Use phishing-resistant recovery controls and throttle the reset endpoint.
04 · SMB turns a credential into evidence
Validate the reset result once, then enumerate shares at that exact privilege level. The aim is to identify artefacts that explain the next boundary, not to collect everything available.
nxc smb "$TARGET_IP" -u '<lab-user>' -p '<lab-password>' --shares; smbclient "//$TARGET_IP/Shared" -U '<lab-user>'The readable share contains a room flag and installers for Spark 2.8.3. That installer is an architectural lead. It does not prove exploitation, but it says the next step is version-aware validation, not more blind enumeration.
05 · Spark and forced authentication
NVD tracks CVE-2020-12772 for the affected Spark release. In the lab scenario, an external image in an in-lab chat message causes a recipient client to retrieve attacker-controlled content and disclose an NTLM challenge-response. It is not a clear-text password, but a weak password may be recoverable through a normal offline wordlist check.
Perform that only against the live TryHackMe machine and only with the room accounts. Capture one response, validate the identity, and use the resulting lab credential once to reach the available remote shell. Do not publish a challenge-response, cracked result, or reusable credential.
whoami; whoami /groups; whoami /priv06 · The dangerous group is not the obvious one
The important output is membership in BUILTIN\Account Operators. Microsoft documents this as a group with limited account-creation privileges, but limited is not harmless. In a misconfigured domain, the ability to modify a non-protected user can reach an account that controls a file share or automation input.
Model the relationship as a graph: who can this principal change, what resources do those accounts access, and which privileged processes consume those resources? Here, an ordinary user profile contains the input file for a scheduled PowerShell task.
Operator memberships should be assigned sparingly, reviewed regularly, and tested against protected groups and business workflows. A group that can reset selected users may indirectly control their automation.
07 · A scheduled task mistakes data for code
Inspection reveals a privileged job running on a short interval. It reads host entries from a user-writable file and evaluates that content rather than treating it as a typed parameter. That is the decisive trust-boundary failure.
Get-Content C:\scripts\checkservers.ps1; Get-Content C:\scripts\log.txtMicrosoft's PowerShell guidance is direct: avoid Invoke-Expression, especially with user-controlled input. Once a high-privilege task evaluates a writable file, the file becomes executable configuration. In the room, the operator-role path permits access to that file through a non-protected account. The controlled proof is the smallest lab-only change that demonstrates the task context, followed by a single execution cycle and confirmation of the final room access.
A SYSTEM task must never parse or evaluate content writable by lower-privileged users. Replace dynamic evaluation with typed parameters, validate hostnames against an allowlist, and restrict the job's input directory to its service owner.
08 · Findings, impact, and fixes
| Finding | Severity | Why it matters | Fix |
|---|---|---|---|
| Biographical reset answer in web asset metadata | HIGH | Enables account recovery without proving identity. | Remove knowledge-based recovery and use verified recovery channels. |
| Outdated Spark client in an authentication workflow | HIGH | Can force NTLM challenge-response disclosure in this lab. | Patch or remove the affected client; restrict automatic external content. |
| Account Operators membership | HIGH | Delegated user control reaches a workflow account. | Apply least privilege and regularly review operator groups. |
| SYSTEM task evaluates writable file content | CRITICAL | Lower-privilege file control becomes privileged code execution. | Remove expression evaluation, use typed input, and lock down ACLs. |
Fixing Spark alone is not enough. The reset design, identity delegation, and unsafe SYSTEM task are independent trust failures. Repair each boundary, then verify the chain is broken with a fresh lab run.
09 · What transfers beyond the lab
- Asset names and content metadata are attack surface. Review them with the same care as visible copy.
- Every credential should have a purpose. A successful login is evidence to enumerate one boundary, not permission to scan blindly.
- Model relationships before escalating. Group membership, ACLs, and task inputs explain the real route.
- Automation deserves a trust-boundary review. Ask who can influence every file, URL, queue, or environment variable it consumes.
- Do not turn data into code. The secure fix is normally to remove dynamic evaluation, not to filter more strings.
References and cross-checks
Primary documentation: