Advanced

Internal network access

To test targets inside a private network, give SimpleSec a way in — either a WireGuard tunnel or a small deployable agent. Both connect only while a test is running.

When you need this

External and web engagements reach their targets over the internet — no setup required. An internal engagement tests hosts inside a private network that SimpleSec can't reach from outside, so you provide a connection method. Once connected, the planner can run the internal chain: Active Directory enumeration, Kerberoasting, AS-REP roasting, BloodHound attack-path analysis, AD CS certificate-template abuse, and lateral-movement validation.

Two ways to connect

WireGuard config

Upload a WireGuard .conf to the engagement. Best when you already run WireGuard or can stand up a peer on the target network.

Deployable agent

Run a small Docker container inside the network. It dials out to SimpleSec, so there are no inbound firewall rules to open.

Option A — WireGuard

  1. Get a WireGuard config for a peer that can reach your internal targets.
  2. Open the internal engagement and upload the .conf to its network settings. The private key is encrypted at rest.
  3. Launch a test as usual. The tunnel comes up automatically when the test starts and tears down when it finishes.

Option B — deployable agent

  1. Deploy the agent container on a host inside the target network, following the setup instructions shown on the engagement.
  2. It dials out to SimpleSec — outbound only, so you don't expose any inbound ports.
  3. Launch your test. The engagement's status flips to Connected once the agent is reachable.
Match the CIDRs to the agent

Set the engagement's internal CIDRs to exactly the ranges the agent actually routes. A mismatched subnet is the most common cause of a run that completes successfully and finds nothing at all — the scan was pointed at addresses the tunnel doesn't carry. If a test comes back empty, check this before anything else.

Supply credentials (recommended)

Unauthenticated internal testing finds what an outsider on the wire would see. Supplying a domain account is what unlocks the full attack chain — and it's how you find out what an account like that could really do.

  1. Open Internal / AD Credentials on the engagement and add a domain account. You can supply a password or an NTLM hash — with a hash, the whole authenticated chain runs pass-the-hash, so a dumped hash keeps working without cracking it first.
  2. Set the domain and privilege tier so the report can grade what that tier was able to reach.
  3. Acknowledge the authenticated-testing consent. Supplied credentials are auth-only and are never sprayed.
Lockout safety

Credentials you supply are used for authentication only. Password spraying is a separate, opt-in action with a per-account failure budget derived from your domain's real lockout policy — capped at three passwords per user.

Pick the right engagement type

The engagement type tunes which tools run. A plain Internal Network engagement covers mixed internal work — SMB shares, databases, file servers — but won't run the AD-specific chain. For Kerberoasting, BloodHound, and AD CS, choose Internal — Active Directory and scope it to the domain controller(s) or the internal range.

What you get back

  • Credentials discovered during the run, redacted in the report body.
  • "N routes to Domain Admin" — BloodHound attack paths, in plain English.
  • AD CS findings across ESC1–ESC15, and — with destructive proofs enabled — an ESC1 certificate proof.
  • A least-privilege audit grading what the account you supplied could actually reach.
Destructive proofs

Off by default. Turning Allow destructive proofs on enables the gated ESC1 certificate mint and deeper BloodHound collection — the difference between "this template is misconfigured" and "here is the certificate that proves it." Leave it off for detection-only runs.

Connection lifecycle

Connectivity is established on test start and torn down on completion — SimpleSec isn't holding a standing tunnel into your network between runs. Each engagement's network profile is isolated from every other, and every scan runs in its own network-isolated sandbox.

Authorization

Internal testing reaches deep into your environment. Only connect networks you're authorized to test, and prefer the agent's outbound-only model where your security policy requires no inbound exposure.