We test the perimeter an internet-based adversary reaches first and the internal environment they land in next. From an exposed management interface to a domain admin ticket, we show you the full route and where to break it.
External testing looks at your organization the way the open internet sees it. Internal testing assumes an attacker is already inside, on a workstation or a network jack, and asks how far they get. Most engagements run both, because the interesting risk lives in how the outside connects to the inside.
We enumerate every host, port, and service you expose to the internet, then test them for real weaknesses rather than reporting a scanner's guesses. That covers default and weak credentials, unauthenticated functionality, injection into internet-facing applications and appliances, and services that should never have been reachable from outside your network in the first place.
Admin panels, hypervisor consoles, database ports, remote desktop, SSH, and device management planes have a way of drifting onto public IP space during a migration or an emergency change. We find the ones that are reachable, test the authentication in front of them, and rate the exposure by what an attacker gains if they get through.
Remote access gateways and mail infrastructure are the front doors attackers knock on daily. We test VPN endpoints for known and configuration-level flaws, weak or absent multi-factor enforcement, and username enumeration, then assess email for spoofing resistance through SPF, DKIM, and DMARC, along with authentication exposure on webmail and single sign-on portals.
We identify services running vulnerable versions and confirm which of those issues are genuinely exploitable in your environment rather than flagged in theory. Alongside missing patches we catch the quieter problems: deprecated TLS, verbose error output, unnecessary services left enabled, and inconsistent hardening across hosts that were meant to share a build.
Internal testing starts from the position a real intrusion reaches after phishing or a compromised device: a foothold on the internal network, often with a low-privileged account. From there we work toward the objectives that matter to you, whether that is domain compromise, access to a sensitive data store, or reaching a segment you believe is isolated.
Active Directory is where most internal compromises are won. We pursue Kerberoasting and AS-REP roasting against weak service and account credentials, abuse of unconstrained and constrained delegation, dangerous ACLs that grant a stepping stone toward higher privilege, and NTLM relay against services that permit it. Each path is traced from the account we start with to the privilege it ultimately yields.
A single compromised host is rarely the goal. We show how an attacker moves between systems using recovered credentials, Kerberos tickets, and trust relationships, through techniques such as pass-the-hash, pass-the-ticket, and remote execution over SMB and WMI. The report records the exact hops so your team can see which controls would have stopped the spread.
We escalate from the access we obtain toward local administrator and, where the path exists, domain-level control. That includes host misconfigurations, weak service permissions, credentials left in scripts, shares, and memory, and Group Policy weaknesses that hand out privilege more broadly than intended. We prove each escalation rather than asserting it from a configuration read.
We test whether the boundaries between your environments actually hold, probing routes from a user subnet into production, cardholder, or management networks that policy says are separated. In parallel we hunt for exposed credentials across open shares, config files, scheduled tasks, and cached secrets, because a reachable password often defeats a well-drawn network diagram.
The sequence is agreed on before any packet leaves our infrastructure. You know what we will touch, from where, in which window, and how we will hand the results back.
We define external ranges, internal subnets, and the domains in scope, then agree on the vantage point for each phase. For internal work that means arranging the foothold itself, whether a jump host, a shipped device, or a standard user account, along with test windows, exclusions, and named contacts on both sides.
We map the attack surface by hand, verify what the tooling reports, and pursue the paths that lead somewhere. Exploitation is rate limited and logged on our side, destructive actions are simulated rather than executed, and we coordinate closely on any system flagged as fragile before we touch it.
You receive the report within five business days of testing completion. Each finding carries reproduction steps, evidence, a CVSS v3.1 rating adjusted for real reachability, and remediation guidance, followed by a live debrief with the people who did the testing.
Once your team ships fixes, we retest every reported finding once at no additional cost and reissue the report with each item marked resolved or still open. You close the engagement with verified remediation, not an open list of claims to chase.
The engagement follows published standards so the result is repeatable and defensible in front of an auditor or a customer. What we test is written down before we start, so there are no surprises about what was and was not covered.
PTES structures the engagement from pre-engagement interaction through exploitation and reporting. NIST SP 800-115 informs how we plan, discover, attack, and document technical testing. MITRE ATT&CK gives us a shared vocabulary for the techniques we use, so your defenders can map every step of the network path we walk against detections they already run.
Standards set the floor, not the ceiling. We test for the issues that matter to your environment even when a checklist does not name them.
The centerpiece of a network engagement is the attack path narrative: the ordered chain of hops from our starting position to each objective, with the specific control that would have broken it named at every step. Leadership reads the risk that chain represents in plain language. Your network and identity teams read the exact hosts, accounts, and misconfigurations behind it.
Findings and evidence travel through an encrypted channel set at scoping, never by plain email, and stay accessible to you after the engagement closes.
Both, and the combination is where the value is. External testing shows what an internet-based attacker can reach and exploit against your perimeter. Internal testing shows how far a foothold spreads once someone is inside. Running them together lets us connect the two, for example an exposed service that yields a credential which then opens internal movement. You can scope either one on its own if that fits your need, and we will tell you plainly which answers your question.
Rather than spending days of budget establishing the initial foothold, we start the internal phase from the position a real intrusion typically reaches: access to a device on your network, often as a standard user. That mirrors what happens after a successful phish or a compromised laptop and concentrates testing time on the question that matters most, which is how far that access can be pushed toward domain compromise or sensitive data. It is the most efficient way to exercise your internal defenses.
Not necessarily. We can begin with no credentials at all, testing what an unauthenticated device on the network can reach and whether we can obtain access through relay, poisoning, and misconfiguration. Providing a standard user account removes the discovery phase and lets us focus on privilege escalation and attack paths through Active Directory, which usually produces more findings per day. We will recommend the starting point that gives you the clearest picture of your real risk.
Disruption in a well-run test is rare and never accidental. We tune scan intensity and timing to your environment, agree test windows during scoping, and coordinate closely on fragile systems such as legacy hosts, industrial equipment, and medical devices before we touch them. Destructive actions are simulated rather than executed, and we stop immediately if monitoring on either side shows instability. Where tolerance is very low, we can validate specific findings under supervision instead of running broad automated activity.
Yes, and it is often the most revealing part of the engagement. We test whether the boundaries your policy describes actually hold at the network level, probing routes from a user or corporate subnet into production, cardholder, management, or other zones you believe are isolated. The report states which boundaries held, which were permeable, and the exact path through any that failed, which is precisely the evidence an auditor or a regulator will ask you to produce.
Tell us what your network looks like and we will propose a scope, a vantage point for each phase, and a timeline within a few business days.