Corporate Attack Surface Audit Planner

You are helping me review the public attack surface of systems that my organisation owns. I have written authorisation to assess them.

In scope (and nothing else):
- (list the domains and systems you own here)

Ground rules:
- Only assets you own or are explicitly authorised in writing to test. If a system belongs to a vendor or a customer, leave it out.
- Get written authorisation from the asset owner first, and tell the people who watch your alerts.
- No exploitation. Identify and describe exposure; do not run exploits, brute force, denial of service, or anything that changes or reads real user data.
- Stay inside the listed scope. If the agent finds something outside it, stop and report it rather than following it.
- No credentials, tokens or customer data go into the prompt or the report. Describe where a secret is, never what it is.
- Keep a record of what was run and when, so the work can be reviewed.

Assume that public-facing systems are already being targeted by others, so favour what is easy to find and easy to use over exotic issues.

When I ask for findings, use this format for each one:
1. Asset (name or host) and why it is in scope
2. Finding, in one sentence
3. Evidence (what was observed, with a reference such as a URL or config path, not a secret)
4. Why it matters: what an attacker could reach from here (the chained path)
5. Severity (critical, high, medium, low) and your confidence (confirmed, likely, unverified)
6. Suggested fix and a suggested owner

Confirm you understand the scope and rules before doing anything.

Using only the scope above and information that is publicly visible, help me build an inventory of what is exposed: hostnames and subdomains, what each appears to run, login pages, admin or debug interfaces, exposed storage, API documentation, and anything that looks forgotten or unowned. Do not exploit anything. For each item say how you know it, and flag anything that should not be public.

For each item in the inventory, review it for common exposure that needs no exploit: missing authentication on an interface, default or example credentials still documented, verbose error pages, exposed configuration or backup files, outdated software versions that match published advisories, weak TLS or missing security headers. Stop at identification. Report in the agreed format.

Take the findings so far and describe, as a written exercise, the shortest path from each exposed item to something valuable inside the organisation (a credential store, a build system, production data, a signing service). Do not attempt any step of the path. Rank the paths by how few steps they need.

Scenario: A developer laptop is compromised. Starting point: One engineer's laptop.

Based on my description of our environment (I will provide it), work through these questions on paper only:
- Which credentials, tokens, SSH keys and cloud sessions are stored on or reachable from that laptop?
- Can the laptop reach production (directly, through a VPN, a jump host or a deployment pipeline)?
- Can it push code or trigger a deployment without a second person approving?
- Which internal systems trust the laptop because of its network position or device certificate?
- Would you see it? Which log would show the first use of those credentials from somewhere new?

Finish with the shortest route from that starting point to production, or state clearly that you cannot find one from what I told you, and list the facts you would need to be sure.

Scenario: A deployment token is stolen. Starting point: A CI or deployment token.

Based on my description of our environment (I will provide it), work through these questions on paper only:
- Where does the token live (CI variables, developer machines, a chat message, a repository)?
- Which environments and services can it deploy to, and does one of them hold signing keys or other high-value secrets?
- Is the token long-lived and unrestricted, or short-lived and bound to a workload?
- Does anything stop the token being used from an unfamiliar network?
- Could you revoke it quickly and tell what it did in the meantime?

Finish with the shortest route from that starting point to production, or state clearly that you cannot find one from what I told you, and list the facts you would need to be sure.

Here is our threat model: [paste who we think would attack us, what they want, and what we cannot afford to lose]. Re-rank the findings against it, and point out any finding that looks minor on its own but matters because of what we cannot afford to lose.