Your network is no longer a wall of ports and hosts. It is a mesh of APIs: external service endpoints, an API gateway out front, east-west traffic between internal services, and admin planes reachable across the wire. Planck Operator maps that API attack surface and tests every operation the way an attacker would, then proves what it finds.
External testing looks at the APIs the open internet can reach: your gateway, your public service endpoints, the management planes that drift onto public IP space. Internal testing assumes an attacker is already inside and asks which internal and service-to-service APIs answer them once they are on the network. Most engagements run both, because the interesting risk lives in how an external API leads to an internal one.
We enumerate every API you expose to the internet, host by host, then test each operation for real weaknesses rather than reporting a scanner's guesses. That covers broken and missing authentication, unauthenticated operations that should require a session, injection on every parameter the endpoint exposes, and service APIs that were never meant to be reachable from outside your network in the first place.
Management and admin APIs, orchestration control planes, database and message-broker APIs, and device management endpoints have a way of drifting onto public IP space during a migration or an emergency change. We find the ones that answer from the outside, test the authentication in front of them, and rate the exposure by what an attacker gains if they reach a privileged operation they should never have been able to call.
The API gateway and the authentication endpoints behind it are the front doors attackers knock on daily. We test token issuance and login operations for forgeable, non-expiring, or weakly signed JWTs, username enumeration, and missing rate limits, then check whether the gateway actually enforces the authorization it advertises or whether a request routed to a backend service reaches an operation the gateway was supposed to block.
We identify APIs running vulnerable or outdated 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 that leaks internals, permissive CORS, and shadow or deprecated API versions left routable long after a newer one shipped.
Internal testing starts from the position a real intrusion reaches after phishing or a compromised device: a foothold on the internal network. From there we map which internal APIs answer a caller on the wire, and how many of them assume the network itself is the security boundary. Internal service APIs, health and debug endpoints, and admin operations that trust anyone inside are tested for the access they hand out without ever asking who is calling.
Most internal compromises are won in the traffic between services. We test the east-west APIs that microservices call on each other: internal REST and gRPC endpoints, service mesh routes, and the tokens they pass around. Where one service trusts another's identity without verifying it, or accepts a token minted for a different audience, we prove the request a compromised service can send to reach data or actions it was never entitled to.
A single reachable API is rarely the goal. We show how an attacker moves between services using tokens, keys, and trust relationships recovered along the way, replaying a credential from one API against the next and chaining a leaked token into a privileged call on a service further in. The report records the exact hops, request by request, so your team can see which controls would have stopped the spread.
We escalate from the access we obtain toward privileged operations and, where the path exists, control of the service itself. That means broken function level authorization, where a low-privileged role calls an admin-only operation, and broken object level authorization, where one caller reads or writes another's records by ID. We replay one role's requests as another to 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.