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
- Get a WireGuard config for a peer that can reach your internal targets.
- Open the internal engagement and upload the
.confto its network settings. The private key is encrypted at rest. - Launch a test as usual. The tunnel comes up automatically when the test starts and tears down when it finishes.
Option B — deployable agent
- Deploy the agent container on a host inside the target network, following the setup instructions shown on the engagement.
- It dials out to SimpleSec — outbound only, so you don't expose any inbound ports.
- Launch your test. The engagement's status flips to Connected once the agent is reachable.
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.
- 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.
- Set the domain and privilege tier so the report can grade what that tier was able to reach.
- Acknowledge the authenticated-testing consent. Supplied credentials are auth-only and are never sprayed.
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.
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.
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.
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.