Writeups

Active Directory Penetration Test: Administrator

Magnus Ensted Danielsen

• 14 min read
Share

Target: administrator.htb domain controller (Hack The Box lab machine, publicly available)
Assessment type: Grey-box, assumed-breach internal Active Directory assessment
Report date: 14 October 2026
Prepared by: Magnus Ensted Danielsen
Pen-testers IP: <redacted>

Portfolio sample. This report documents an authorised assessment of the publicly available Hack The Box "Administrator" training machine, written to professional engagement-report standard to demonstrate testing methodology and reporting. It contains no real client, customer or confidential data.

Scope

Item Detail
In scope The administrator.htb Active Directory environment and its domain controller, assessed from the perspective of an authenticated domain user.
Out of scope Denial-of-service testing, social engineering, and any system outside the administrator.htb domain.
Objective Assess the security posture of the Active Directory environment and determine the highest level of access reachable from a single low-privileged domain account.

The assessment was conducted as an assumed-breach exercise: testing began from one set of valid low-privileged domain credentials (the Olivia account), modelling an attacker who has obtained a standard user account through phishing, password spraying or credential reuse. This is the realistic starting point for most internal Active Directory engagements, where the question is not whether an attacker can get a foothold, but how far a single foothold can be extended.

Executive Summary

The assessment started with the access of a single ordinary employee account and ended with complete control of the organisation's entire network of user accounts and computers. This is the highest level of access that exists in a Windows environment. It means being able to read, change or delete any data, reach any system, and act as any employee, including the most senior administrator.

Reaching this point did not require any clever hacking of software or any unknown security flaw. Instead, the environment had been set up in a way that quietly allowed one account to take over another, and that account to take over the next, and so on. It worked like a set of keys where each key happened to open the drawer holding the next key. Following that trail from the starting account led, step by step, all the way to the master key for the whole environment.

Along the way, two further problems made the path easier. A file containing saved passwords had been left on a service the attacker could reach, and several passwords in the environment were simple enough to be guessed by automated tools within seconds.

In practical business terms, this means that if any single employee's password were stolen or guessed, an attacker could realistically take over the entire environment. From there they could steal or destroy all company data, lock every system with ransomware, and set up hidden ways to return later. Because none of this needed specialist skill or inside knowledge, a real attacker would have a good chance of succeeding.

The problems fall into three groups: accounts given far more control over other accounts than they needed, a saved-password file left in an exposed location, and weak passwords. The most important action is to review and remove the excessive control permissions between accounts, because those permissions are what made the whole chain possible. A prioritised list of fixes follows immediately below, with full technical detail for each issue in the sections after it.

Findings Summary

# Finding Severity
1 Excessive Directory Replication Rights (DCSync) Granted to a User Account Critical
2 Dangerous Password-Reset Permissions Between User Accounts High
3 Sensitive Credential Store Exposed via FTP High
4 Writable Service Principal Name Enables Targeted Kerberoasting Medium
5 Weak, Dictionary-Crackable Account Passwords Medium
6 Kerberos RC4 Encryption Permitted, Enabling Offline Ticket Cracking Low

Remediation Summary

Actions are ordered by priority, reflecting the combination of severity and ease of exploitation. Item 1 removes the most direct route to full compromise and should be treated as the immediate priority.

Priority Finding Recommended action Effort
1 Finding 1 Restrict directory replication rights (DS-Replication-Get-Changes and -All) to domain controllers only. No standard user account should hold them. Low
2 Finding 2 Audit and remove GenericAll, WriteDacl, WriteOwner and ForceChangePassword rights held by non-administrative accounts over other users. Apply least privilege. Medium
3 Finding 4 Remove write access to other accounts' servicePrincipalName attribute from non-administrative users. Low
4 Finding 3 Remove the saved-password file from FTP, retire FTP in favour of an encrypted alternative, and rotate every credential it exposed. Medium
5 Finding 5 Enforce a strong, breach-screened password policy and move service accounts to Group Managed Service Accounts (gMSA). Medium
6 Finding 6 Disable Kerberos RC4 and require AES across the domain. Low
7 Findings 1, 2, 4 Deploy monitoring and alerting for password resets, SPN changes and replication requests that originate from anything other than a domain controller. Medium

Recommended sequence. Treat the Active Directory permission issues (items 1, 2, 3 and the monitoring in item 7) as the priority, because excessive permissions are the common thread through every stage of the compromise. Address the exposed password file (item 4) and the password weaknesses (items 5, 6) in parallel. After remediation, a focused retest is recommended to confirm the privilege-escalation chain can no longer be reproduced from end to end.

Attack Chain: High-Level Overview

This is the high level overview of how the assessment moved from a single ordinary account to full control. Each step used only the access gained in the previous one.

  1. Starting from one ordinary employee account, a map of the environment's accounts and their permissions showed that this account was allowed to reset another account's password.
  2. That gave access to a second account, which in turn was allowed to reset a third account's password.
  3. The third account could reach a file-sharing service where a saved-password file had been left. Opening that file, which was protected by a weak password, revealed a fourth account.
  4. The fourth account could change a setting on a fifth account that exposed its password in a recoverable form. That password was also weak and was recovered quickly.
  5. The fifth account had been given a special permission normally reserved for the servers that run the network. This permission allowed every password in the environment to be copied, including the master administrator account.
  6. With the administrator account's credentials, the assessment logged in with full control of the environment, completing the objective.

The themes behind these steps, excessive permissions between accounts, an exposed password file, and weak passwords, are documented as formal findings later in this report.

Attack Chain including technical details

This section goes more technically indepth showcasing the assessments attack chain. Each step cross-references the formal finding that documents it in full, including commands and evidence.

Reconnaissance. An nmap sweep returned the classic domain-controller fingerprint (Kerberos on 88, LDAP on 389 and 3268, SMB on 445, DNS on 53), alongside an open FTP service on 21 and a clock skew of roughly seven hours to account for in later Kerberos requests. The domain administrator.htb and the DC hostname were added to /etc/hosts. Using the Olivia credentials, enum4linux-ng confirmed that SMB signing was required, enumerated ten domain users and the group structure over RPC, and listed the default shares. The readable shares held only standard Group Policy content, so enumeration moved from files to Active Directory permissions.

Step 1, password-reset chain (Finding 2). BloodHound, loaded with the Olivia credentials, showed that Olivia held GenericAll over Michael. This allowed Michael's password to be reset with bloodyAD without knowing the current one. Repeating the process, Michael held ForceChangePassword over Benjamin, which was abused identically to take over Benjamin.

Step 2, exposed credential store (Findings 3 and 5). The Benjamin account could authenticate to the FTP service. A single file, Backup.psafe3, a Password Safe v3 vault, sat in its root. The vault was retrieved and its master password recovered offline with hashcat in seconds, revealing the Emily domain account.

Step 3, targeted Kerberoasting (Findings 4, 5 and 6). Emily held GenericWrite over Ethan, which allowed a Service Principal Name to be written to Ethan. This turned Ethan into a Kerberoastable target even though it had no service role. The resulting service ticket was issued using RC4 encryption and was cracked offline with hashcat, revealing the Ethan account.

Step 4, domain compromise (Finding 1). Ethan held directory replication rights. Running Impacket's secretsdump.py against the domain controller, the SAM-based method was denied and the tool fell back to the DRSUAPI method, a DCSync, which replicated every account's password hash, including the built-in Administrator. That hash was used directly in a pass-the-hash login with evil-winrm, establishing an interactive session with full Domain Administrator privileges.

The net result was that an attacker holding one ordinary account, and no special access, could reach complete control of the environment using only standard tooling.

Finding 1: Excessive Directory Replication Rights (DCSync) Granted to a User Account

Severity: Critical
CWE: CWE-266 (Incorrect Privilege Assignment), CWE-269 (Improper Privilege Management)
CVSS 3.1: 9.6 (Critical), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Summary

The Ethan user account held directory replication rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), the permissions that allow a system to request a copy of account secrets from a domain controller. These rights are intended only for domain controllers and a small number of administrative services. Granted to an ordinary user account, they allow that account to perform a DCSync, pulling every password hash in the domain directly from the domain controller.

Impact

This single misconfiguration is, on its own, enough to compromise the entire domain. Any attacker who controls the account can replicate the password hash and Kerberos keys of every user, including the built-in Administrator and the krbtgt account. The Administrator hash enables a pass-the-hash login as Domain Administrator with no cracking required, and the krbtgt key enables long-term forged-ticket persistence. The result is total loss of confidentiality, integrity and availability across the domain.

Remediation

  • Remove directory replication rights from every account that is not a domain controller. Review which principals hold DS-Replication-Get-Changes and -All, and revoke them wherever they are not strictly required.
  • Alert on replication requests (DRSUAPI GetNCChanges) that originate from anything other than a known domain controller. These are a reliable indicator of a DCSync attack in progress.
  • Rotate the krbtgt password twice if a DCSync by an untrusted party is suspected, to invalidate any forged tickets.

References

Technical reproduction and evidence

Using the Ethan account (recovered via Finding 4), the replication right was exercised with Impacket's secretsdump.py. The SAM-based method was denied and the tool fell back to the DRSUAPI (DCSync) method, which replicated every account's secrets:

$ secretsdump.py administrator.htb/ethan:'<redacted>'@dc.administrator.htb
[-] RemoteOperations failed, falling back to DRSUAPI
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Administrator:500:<redacted>:<redacted>:::
krbtgt:502:<redacted>:<redacted>:::
... (all domain accounts replicated) ...

The recovered Administrator NT hash was then used directly in a pass-the-hash login, giving an interactive session with full Domain Administrator privileges:

$ evil-winrm -i dc.administrator.htb -u Administrator -H '<redacted>'
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
administrator.htb\administrator

Finding 2: Dangerous Password-Reset Permissions Between User Accounts

Severity: High
CWE: CWE-266 (Incorrect Privilege Assignment), CWE-269 (Improper Privilege Management)
CVSS 3.1: 7.7 (High), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Summary

Ordinary user accounts had been granted permissions that let them reset the passwords of other user accounts without knowing the existing password. Two instances were abused during the assessment:

  • Olivia held GenericAll over Michael. GenericAll is full control of the target object, which includes resetting its password.
  • Michael held ForceChangePassword over Benjamin, a permission whose only purpose is to reset another account's password.

Neither relationship reflects a normal business need, and both were discoverable with standard Active Directory mapping tools. Each one lets an attacker take over the target account outright.

Impact

These permissions let the assessment move from one account to the next by resetting passwords, forming the early links of the chain that ended in full domain compromise. More generally, any account that can reset another account's password effectively controls that account, so permissions of this kind collapse the boundary between a low-privileged user and whatever the target can reach. Resetting a password is also disruptive, because it locks the legitimate owner out until the change is noticed.

Remediation

  • Audit account-over-account permissions and remove GenericAll, GenericWrite, WriteDacl, WriteOwner and ForceChangePassword rights held by non-administrative users over other accounts.
  • Apply least privilege so that password resets are performed only by designated administrative roles or a controlled self-service system.
  • Alert on password resets performed by accounts that are not recognised administrative principals.

References

Technical reproduction and evidence

Permission edges were identified with BloodHound using the low-privileged account, then abused with bloodyAD. Resetting Michael using Olivia's GenericAll:

$ bloodyAD --host dc.administrator.htb -d administrator.htb \
      -u Olivia -p '<redacted>' \
      set password michael '<redacted>'
[+] Password changed successfully!

The same technique was then applied with Michael's ForceChangePassword right to reset Benjamin, taking over that account and providing the FTP access used in Finding 3.

Finding 3: Sensitive Credential Store Exposed via FTP

Severity: High
CWE: CWE-522 (Insufficiently Protected Credentials), CWE-312 (Cleartext Storage of Sensitive Information)
CVSS 3.1: 7.7 (High), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Summary

A personal password-manager database (Backup.psafe3, a Password Safe v3 vault) was stored in the FTP area reachable by the Benjamin account. Any user able to authenticate to that FTP service could download the entire vault. Once retrieved, the vault could be attacked offline at no risk of detection, and its contents, the credentials for the Emily domain account, recovered in full.

Storing a credential vault on a shared file service removes the protection a password manager is meant to provide. The whole encrypted database is handed to the attacker, who then only has to defeat the master password offline (see Finding 5).

Impact

The exposed vault bridged the attack from one compromised account to another, providing the credentials needed to continue the privilege-escalation chain. More generally, any credential store reachable over a file-transfer service is a high-value target, because a single file can expose multiple accounts, service passwords or keys at once. FTP also transmits credentials and data without encryption, exposing them to network interception.

Remediation

  • Remove sensitive files such as credential vaults, backups and configuration files from FTP and other shared services. Store secrets only in a controlled, access-audited secrets manager.
  • Decommission FTP in favour of an encrypted, authenticated alternative such as SFTP or FTPS, and ensure file services enforce least-privilege access scoped per user.
  • Rotate any credential that was stored in, or protected by, the exposed vault, including the recovered domain account.
  • Educate staff that personal password-manager exports must never be placed on shared infrastructure.

References

Technical reproduction and evidence

Using the Benjamin credentials recovered in Finding 2, authenticate to the FTP service and retrieve the vault:

$ ftp [email protected]
ftp> ls
Backup.psafe3
ftp> get Backup.psafe3

The downloaded database was then cracked offline (see Finding 5), revealing the Emily domain credentials.

Finding 4: Writable Service Principal Name Enables Targeted Kerberoasting

Severity: Medium
CWE: CWE-266 (Incorrect Privilege Assignment), CWE-269 (Improper Privilege Management)
CVSS 3.1: 6.5 (Medium), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Summary

The Emily account held GenericWrite over the Ethan account, which includes the ability to write to its servicePrincipalName attribute. Kerberoasting, a technique that recovers an account's password from a service ticket, normally only works against accounts that already have a Service Principal Name. Write access to that attribute lets an attacker create one on demand, turning any ordinary account into a Kerberoastable target. This is known as targeted Kerberoasting.

Impact

This permission let the assessment obtain a crackable service ticket for the Ethan account, which was the account that ultimately held the replication rights in Finding 1. On its own, the weakness exposes the password of any account an attacker can add a Service Principal Name to, which is especially serious when that account is privileged. The practical impact depends on the strength of the target account's password (see Finding 5) and the encryption used for its ticket (see Finding 6).

Remediation

  • Remove write access to other accounts' servicePrincipalName attribute from non-administrative users. Review GenericWrite, GenericAll and WriteProperty rights over user objects and apply least privilege.
  • Use Group Managed Service Accounts (gMSA) for any account that genuinely needs a Service Principal Name, so that its password is long, random and managed automatically.
  • Alert on changes to the servicePrincipalName attribute, which are rare in normal operation and a strong indicator of this attack.

References

Technical reproduction and evidence

Emily's GenericWrite over Ethan was used to write a Service Principal Name to Ethan, manufacturing a Kerberoastable target. The resulting request returned an RC4 ($krb5tgs$23$) ticket (see Finding 6), which was cracked offline:

$ bloodyAD --host dc.administrator.htb -d administrator.htb \
      -u Emily -p '<redacted>' \
      set object Ethan servicePrincipalName -v 'fake/svc'
[+] Ethan's servicePrincipalName has been updated

$ nxc ldap dc.administrator.htb -u Emily -p '<redacted>' --kerberoasting out.txt
$krb5tgs$23$*Ethan$ADMINISTRATOR.HTB$...<redacted>...

$ hashcat -m 13100 ethan_tgs.txt rockyou.txt
Status...........: Cracked

Finding 5: Weak, Dictionary-Crackable Account Passwords

Severity: Medium
CWE: CWE-521 (Weak Password Requirements)
CVSS 3.1: 6.5 (Medium), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Summary

Several secrets in the environment were weak enough to be recovered almost instantly with a standard public wordlist (rockyou.txt). These included the master password of the exposed password vault (Finding 3) and the service account password recovered through targeted Kerberoasting (Finding 4). Where credential material can be obtained in a crackable form, such as an encrypted vault or a Kerberos ticket, weak passwords turn a theoretical offline attack into an immediate one.

Impact

Weak passwords removed the only remaining effort from two key steps in the chain. A strong, high-entropy password on the vault or on the Kerberoastable account would have left the attacker with encrypted material that was computationally infeasible to crack, which would likely have stalled the chain. Weak passwords are also directly exploitable through password spraying against the domain, independently of the other findings.

Remediation

  • Enforce a strong password policy with a high minimum length (15 or more characters for user accounts, longer for service accounts) and screening against breached-password and dictionary lists, so that values like those recovered here are rejected.
  • Use managed, randomly generated passwords for service accounts, ideally Group Managed Service Accounts (gMSA), which remove human-chosen passwords from Kerberoastable accounts entirely.
  • Monitor for password spraying and repeated authentication failures across accounts.

References

Technical reproduction and evidence

Both the Password Safe vault and the Kerberos service ticket were recovered offline with hashcat against rockyou.txt, using the appropriate hash modes. Both cracked in seconds, confirming the underlying passwords offered no meaningful resistance:

$ hashcat -m 5200 Backup.psafe3 rockyou.txt      # Password Safe v3 vault
Backup.psafe3:<redacted>
Status...........: Cracked

$ hashcat -m 13100 ethan_tgs.txt rockyou.txt     # Kerberos 5 TGS-REP (etype 23)
Status...........: Cracked

Finding 6: Kerberos RC4 Encryption Permitted, Enabling Offline Ticket Cracking

Severity: Low
CWE: CWE-326 (Inadequate Encryption Strength), CWE-327 (Use of a Broken or Risky Cryptographic Algorithm)
CVSS 3.1: 3.1 (Low), CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Summary

The domain issued Kerberos service tickets encrypted with RC4 (encryption type 23). RC4-encrypted tickets are significantly faster to crack offline than their AES equivalents, which is what made the Kerberoasting step practical. The ticket obtained for the Ethan account (see Finding 4) was returned in RC4 form and cracked in seconds.

This is a hardening weakness rather than a direct vulnerability. It does not grant access on its own, but it materially lowers the cost of attacks that depend on cracking Kerberos tickets.

Impact

Permitting RC4 reduces the protection that a strong service-account password would otherwise provide, because weaker encryption makes offline cracking faster and cheaper. Combined with the writable Service Principal Name in Finding 4 and the weak passwords in Finding 5, it was a contributing factor in the compromise of the Ethan account.

Remediation

  • Disable RC4 for Kerberos and require AES (AES128 and AES256) across the domain, after confirming that no legacy systems depend on RC4.
  • Prefer gMSA for service accounts, so that even AES-encrypted tickets protect a long, random password that is infeasible to crack regardless of algorithm.
  • Monitor for RC4 ticket requests (encryption type 0x17), which are a strong indicator of Kerberoasting activity.

References

Technical reproduction and evidence

The Kerberoast request issued for Ethan in Finding 4 returned an RC4 ($krb5tgs$23$) ticket, confirming RC4 issuance. The 23 in the hash prefix denotes encryption type 23, which is RC4-HMAC, and the ticket was cracked offline in seconds:

$ nxc ldap dc.administrator.htb -u Emily -p '<redacted>' --kerberoasting out.txt
$krb5tgs$23$*Ethan$ADMINISTRATOR.HTB$...<redacted>...

$ hashcat -m 13100 ethan_tgs.txt rockyou.txt
Status...........: Cracked