Out-of-the-Box and Lateral Thinking in Attack Chains
Domain 8 tests judgment as much as creativity. The exam rewards testers who chain low-severity observations into a credible attack path, and penalises those who confuse imagination with unauthorised action. Lateral thinking means asking what an asset trusts, not what ports it opens.
The trust-graph mindset
Build a graph of trust relationships rather than a list of vulnerabilities. Who can read this database? Which CI runner deploys to production? Which internal service trusts a header, a certificate, or an IP range? Useful vectors include verbose error pages leaking internal hostnames, password reuse across the perimeter and the VPN, cloud metadata endpoints at 169.254.169.254 granting role credentials, exposed CI/CD tokens in repositories, and stale DNS records pointing to deprovisioned cloud resources. ATT&CK technique identifiers give the chain a common vocabulary.
Chaining and pivoting
Once a foothold exists, pivoting extends reach: SSH local and remote forwards, proxychains with SOCKS, Chisel, ligolo-ng, or a Meterpreter route. The chain is only as strong as its weakest verified link, so document each hop with source, destination, port and timestamp. Creativity is bounded by the RoE: if the scope lists only the DMZ, a discovered internal hostname is a lead to report, not a target to scan.
Worked example
A low-severity finding - a stack trace on a public endpoint - reveals the internal hostname gitlab.corp.local. The tester notes it, confirms with the client that internal hosts are in scope, then resolves it through the VPN foothold already authorised. The internal GitLab allows self-registration, the default project template contains a CI runner registration token, and the runner executes jobs on a deployment host. The chain is documented as four verified hops with a stop condition before touching production deployment credentials, and reported as a single critical path with four contributing weaknesses.
Traps that cost marks
- Chasing a chain outside the agreed scope because it was technically reachable.
- Reporting only the final hop; the client cannot fix what you cannot explain.
- Over-claiming impact from a theoretical chain where one link was never verified.
- Using a destructive payload to prove a point when a read-only check would do.
- Ignoring the blue-team detection opportunity, which is often the most valuable output of a creative chain.