Integrate a standalone or assumed-breach AD attack

Needs: An assigned objective and current host/identity/route map; each next method's enabling conditions must be produced or discovered

Client commands / example output

Record scope, objective, source position and evidence requirements.

Establish TCP coverage, bounded UDP coverage and confirmed application identities.

Enumerate every confirmed service in its anonymous/current context; map web requests, hosts, parameters, content and roles.

Search files, configuration, repositories and application data for identities or prerequisites.

Build candidate cards for manual application weaknesses, compatible credentials and exact public-exploit prerequisites.

Validate one prerequisite at a time and prove the smallest useful effect.

Convert execution into a verified session; record host, identity, privilege, interfaces and routes.

Capture the initial-access transition and any required unprivileged objective before changing state.

Enumerate local privilege paths as controlled object → effective permission → privileged consumer → trigger → effect.

Verify the elevated identity, capture required evidence, re-enumerate protected context and remove exercise artifacts.

Reconstruct the ordered reproduction path while the commands and assumptions are still known.

Failure at a step returns to its owning block. Do not skip service enumeration because one banner suggests a CVE, and do not start privilege escalation before proving which host and identity the shell represents.

# Baseline
starting credential
→ local/domain identity + DNS/time/DC context
→ reachable host/service map
→ users/groups/computers/shares/SPNs/ACLs/sessions
→ ranked identity or host transition
→ compatible password/hash/ticket use
→ verified session/new identity
→ re-enumeration
→ route/movement to next host
→ higher domain privilege/objective

# Keep five variables together for every edge
controlled identity
effective group/right
target object or host
required protocol/route
resulting identity/access

BloodHound and enumerators generate candidate edges. Validate the underlying group membership, ACL, session, service right, route and authentication material before acting. After every new identity or host session, repeat authenticated enumeration rather than continuing from the old authorization view.

Verify → For every transition record its prerequisite evidence and independently verified effect; no step is complete because the next tool launched.

If it fails → A broken route or invalid account context can halt an otherwise plausible chain. Return to the first unmet prerequisite. More detail ↓

If → then

A download/path parameter or URL segment influences a local filename → Read files through directory traversal
Needs: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
Domain credentials or a domain-joined foothold → Establish domain identity, DC, DNS, time and route
Needs: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew
Access, privilege, identity or route changes, or a report will need reproduction → Capture state-transition, proof and exploit-adaptation evidence
Needs: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Integrate a standalone or assumed-breach AD attack

USE WHEN: Individual techniques are understood but the full path must be selected independently
STARTING ACCESS: An assigned objective, scope and accumulated host/identity/route evidence
RESULT: A coherent chain of verified capability transitions

Recognize the clue

Take the current verified capability and compare it with the receiving method's starting access and missing conditions.

CURRENT RESULT -> CANDIDATE NEXT METHOD -> REQUIRED INPUT -> MISSING PROOF

SYNTHETIC EXAMPLE OUTPUT

Result: file read
Proposed next step: SSH
Missing input: usable key/password and matched user

Means: A file read does not itself create a shell; the chain needs an actual credential/identity transition.

Confirm: Verify every produced material type, account, route and service-specific right before connecting the next step.

After validation: Each receiving method's prerequisites are supplied by verified state: follow the connected chain.
Ruled out in this context: The proposed next method requires a capability not produced or available: reject that handoff.
Still inconclusive: An inferred secret or stale account association keeps the chain provisional.

Troubleshooting: A broken route or invalid account context can halt an otherwise plausible chain. Return to the first unmet prerequisite.

Additional prerequisite checks

OBSERVATION -> ENABLED METHOD -> VERIFIED CAPABILITY -> NEW STATE -> RE-ENUMERATION

Use the earlier procedure linked at each transition; the integration layer owns order and state:

Record scope, objective, source position and evidence requirements.
Establish TCP coverage, bounded UDP coverage and confirmed application identities.
Enumerate every confirmed service in its anonymous/current context; map web requests, hosts, parameters, content and roles.
Search files, configuration, repositories and application data for identities or prerequisites.
Build candidate cards for manual application weaknesses, compatible credentials and exact public-exploit prerequisites.
Validate one prerequisite at a time and prove the smallest useful effect.
Convert execution into a verified session; record host, identity, privilege, interfaces and routes.
Capture the initial-access transition and any required unprivileged objective before changing state.
Enumerate local privilege paths as controlled object → effective permission → privileged consumer → trigger → effect.
Verify the elevated identity, capture required evidence, re-enumerate protected context and remove exercise artifacts.
Reconstruct the ordered reproduction path while the commands and assumptions are still known.

Failure at a step returns to its owning block. Do not skip service enumeration because one banner suggests a CVE, and do not start privilege escalation before proving which host and identity the shell represents.

Keep five variables together for every edge:

BloodHound and enumerators generate candidate edges. Validate the underlying group membership, ACL, session, service right, route and authentication material before acting. After every new identity or host session, repeat authenticated enumeration rather than continuing from the old authorization view.

For multihop work, maintain a route diagram and a separate callback diagram. A route that permits an operator tool to reach a service does not prove that a payload can return to its handler.

Why it works

A chain is connected by capabilities, not chapter order. File read may produce a key, a session may expose another subnet, and a new identity returns to authenticated enumeration.

Worked example · hypothetical

Observation: a web read yields an application credential. Test: validate its source identity, then justified SSH reuse. Illustrative output: SSH gives a Linux foothold whose sudo rule enables a root transition. Interpretation: retain separate evidence for read, authentication, session and privilege.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗