Service
Internal & External Penetration Testing
Find the paths into your network, and the paths across it once someone is in.
Two questions, tested separately because they have different answers. What can somebody reach from the internet, and what happens once somebody is already inside. Most organisations have a defensible answer to the first and have never seriously tested the second, which is the one that decides how bad a bad day gets.
How this works
External: what the internet can reach
Enumeration first, because the finding is usually something nobody knew was exposed. Certificate transparency logs, DNS, cloud inventory and the routing layer between them will surface hosts that no asset list has, and those hosts are the ones running an old version of something. From there: exposed services and their versions, authentication that accepts weak or reused credentials, admin interfaces that are protected only by not being linked, and file services left open to anonymous listing.
Internal: what a foothold is worth
Testing starts from an assumed position, typically a standard user account or a compromised workstation, because that is where a real intrusion begins rather than at the perimeter. The work is then a graph traversal: which machines does this account administer, which accounts are logged into those machines, what does that get, repeat. Active Directory is where this usually goes, and the routes that keep working are permissions somebody granted deliberately rather than a missing patch.
Chains, not counts
A scanner reports issues in isolation and grades each one alone. The findings that matter are almost always compositions: a low-severity information disclosure that gives a username format, a service account with a weak password, a share that account can read, credentials in a script on that share. Individually all minor. Together they are domain admin. Findings are reported as the path, with the whole chain written out.
Retest included
A fix is not proven by a code change or a ticket moving to done. Every finding is retested against the remediated system, and the retest result is part of the report rather than a separate engagement.
What we look for
- Externally reachable services nobody knew were exposed, including forgotten subdomains and cloud resources outside the main account
- Password reuse and weak credentials on services that permit authentication attempts at volume
- Active Directory paths from a standard user to a privileged one: nested groups, unconstrained delegation, over-permissioned service accounts
- Kerberoastable accounts with privileges they never needed
- Local administrator rights shared across machines, which turns one compromised host into all of them
- Credentials stored in scripts, shares, group policy and deployment tooling
- Segmentation that exists on a network diagram but not in the routing table
What you get
- A report an engineer can act on, with reproduction steps for every finding
- A separate summary written for people who will not read the technical detail
- Findings ranked by what they let an attacker do, not by raw CVSS
- Attack paths written out end to end, so the fix can be aimed at the cheapest link to break
- A retest of the fixes once you have made them
What this does not include
- Denial of service testing, or anything else whose success condition is an outage
- Social engineering of your staff, unless you scope it deliberately as a phishing engagement
- Physical access testing
- Changes to your systems: findings are demonstrated, not remediated on your behalf
Questions people ask
- Do you need credentials?
- For external testing, no. For internal testing, yes, and the engagement is more useful with them. Testing from an unauthenticated position tells you what a stranger on your network can do; testing from a standard user account tells you what a phished employee can do, and that is the scenario that actually happens.
- Will this disrupt production?
- Testing is designed not to, and anything with a real chance of causing an outage is agreed with you in advance or left out. Exploitation is used to prove a finding, not to see how far it goes. If a system is fragile enough that ordinary testing risks it, that is itself worth knowing and gets reported.
- How is this different from a vulnerability scan?
- A scan finds known issues in known software. It cannot chain findings, reason about your business logic, or tell the difference between a vulnerable version that is unreachable and one that is exposed. Both have a place, and the scan is the cheaper starting point if you have never done either.