Penetration testing: where infrastructure fails
Infrastructure vulnerabilities rarely look like a code error.
More often, failure comes from a side no one considered production: a test environment exposed externally "temporarily," an admin panel with default configuration, a port opened for debugging and forgotten after release. Formally, everything works, but the external perimeter is wider than the team assumes.
Outdated accounts are the most common class of hidden entry points. A service account used by a departed contractor, a key not revoked after migration, an admin-privileged role on an account that only needs to read metrics. Such records are invisible in inventory and do not hinder the product—they simply wait to be found.
From the external perimeter, this does not look like a breach but like a chain: scanning finds an open service, the service accepts credentials no one changed, then movement continues inside the network through trusted relationships.
The network perimeter is considered protected because the rule list is formally closed—the discrepancy between the diagram and reality is the subject of the test.
The cost of failure is not only a leak. The product degrades unnoticed: some requests go to a compromised node, logs are collected incompletely, and recovery drags on because no one has an up-to-date relationship map.
Penetration testing is conducted not for the report, but to compare real entry points with what the team considers its perimeter—we break down how this gets closed.
What changes after reviewing perimeters and access rights
After reviewing perimeters and access rights, the work does not end with a report: every discrepancy becomes a change to service configuration or policy. We conduct the review using OWASP methodologies and record not only the vulnerability but also the class of failures it opens.
The vulnerability window shrinks from weeks to hours
Previously, a critical update waited for the nearest maintenance window, and the vulnerability window stretched to two or three weeks. Now services with external access are placed in an urgent queue, and the closure deadline is fixed for each perimeter.
The share of successful login attempts falls
We revoke shared accounts, reduce access rights to the necessary minimum, and limit key lifetimes. Logins from atypical locations stop succeeding, while legitimate scenarios continue to work.
Response time is measured in minutes
The event reaches the on-call engineer with context: account, source, series of attempts. The response procedure describes the first step and the owner—without calls and clarifications.
| Risk class | What we check | What changes |
|---|---|---|
| External perimeter | published services | close unnecessary access |
| Access rights | excessive privileges and shared accounts | narrow to the necessary |
| Segmentation | reachability of critical nodes | narrow rules to required directions |
| Response | existence of a procedure and owner | assign an owner and failure class |
The result is not a list of comments, but changed configuration and a working procedure: the vulnerability window is measured in hours, not weeks.
Work formats: external perimeter, internal network, web applications
Penetration testing begins not with a set of tools, but with choosing boundaries: the same methodologies produce different results from outside and from inside the network. Below are the options that are actually chosen between, and what limits each of them.
| Option | When it fits | Limitations |
|---|---|---|
| External perimeter | There are public addresses and services accessible from the internet | Security and monitoring systems see the test: agreed windows and an exact list of addresses are required |
| Internal network | Need to understand what is available to an attacker after compromising one workstation | Requires an entry point into the segment and separate access; there is a risk of affecting production services |
| Web applications | A product with a personal account, payments, file uploads | Test accounts for all roles and a copy of data are required; we exclude destructive tests |
| Software interfaces | Services exchange data and expose it to external consumers | Part of the logic is hidden from the observer; keys and a request rate limit are required |
| Mobile clients | There is an application for mobile platforms | A test build and environment are required; we separately check data storage on the device |
External perimeter
Here the task is to see the organization through the eyes of someone with no access at all.
Before starting, we agree on addresses, time windows, and the on-call shift contact: then the test does not turn into a nighttime incident, and findings immediately receive priority based on external reachability.
Internal segments
Work inside begins with an attacker model: which account and which rights we consider compromised. Then we look at segmentation, trust relationships between domains, and access to storage—what is not visible from outside but decides the outcome as an attack develops.
Stages: from agreeing on boundaries to report handover
The work proceeds in sequential stages: each next one relies on an artifact from the previous one, so the result is reproducible and does not depend on which engineer leads the project. Below is the order in which we conduct penetration testing.
Work order
- Perimeter audit: inventory of external addresses, internal subnets, and integration points—an attack surface map with an owner for each node.
- Boundary agreement: address ranges, work windows, prohibition of destructive scenarios, on-call contact—we document everything in writing.
- Test plan: we lay out scenarios by risk class and move a copy of configurations to a test environment, where we test dangerous hypotheses.
- Work in the production environment—according to agreed scenarios within the permitted window, recording the time and result of each step.
- Verification of findings: we confirm each hypothesis by a second independent method; otherwise a false positive enters the report.
- Retest: after remediation, we return to the same points using the same scenario and make sure the vulnerability is closed.
- Report handover with priorities, reproduction steps, and recommendations, separately—what consciously remained outside the test.
Verification and retest
Written boundaries, a plan, and confirmed findings provide a reproducible route: the test can be repeated and snapshots compared, rather than relying on participants' memory.
Test artifacts: report, evidence, remediation plan
Penetration testing is considered complete not when findings are discovered, but when the client's team has a set of documents by which they can close them without the testers' involvement. Here is what we hand over based on the results of the work.
- Test report — findings with an exploitation vector, affected perimeter, and criticality assessment; each is tied to a specific node, not to generic advice.
- Evidence — sequences of requests and responses, logs, state dumps: they can be used to reproduce a finding and confirm that remediation occurred.
- Perimeter diagram — a map of segments, entry points, and trust relationships between services, assembled as-is, not from design documentation.
- Access policies — rules for service accounts, administrative access, and inter-segment routes, with notes on where the principle of least privilege is violated.
- Remediation plan — priorities: what is closed by configuration, what requires architecture changes, and what requires organizational measures.
- Retest procedure — frequency and triggers: perimeter change, major release, access rotation.
Readability for engineers. Each item is described in four blocks: finding, reproduction, impact, remediation—this is enough to create a task without clarifications from the testers.
For management, there is separately a criticality summary and a traceability matrix showing exactly which test confirmed closure.
Case study: how a failure class was closed in the integration perimeter
The client is a platform with a distributed integration perimeter: external interfaces for partners, an event queue, service accounts, notifications from external systems.
Before this, penetration testing was done once a year and only on the external perimeter, while connections between services inside were considered closed by network segmentation.
The implementation case began with an inventory: all entry points were placed on the map, including test environments and admin interfaces left over from previous releases.
Metrics before and after
According to the previous review, the report listed 4 findings, and about half of them were closed—the fixes stalled in approvals, and the response time to a new finding was measured in weeks.
After inventorying entry points, there were 34, of which 9 had a confirmed ability to escape the service boundary.
Vulnerability remediation proceeded by priority: rotation of service account keys, separation of rights between services, moving admin interfaces to a separate segment. The retest did not confirm any of the 9, and the response time to a finding decreased from weeks to a few days.
Why findings are not fixed in one pass
Some vulnerabilities entail a change in the interaction scheme: fixing authorization in one service breaks calls in two others. Such changes come in waves—first what is closed by settings, then code fixes, then disabling outdated entry points.
Findings were labeled according to OWASP so that priorities did not depend on who reads the report. The share of closed items was calculated not from the report itself, but from the retest—which also showed what remained outside the perimeter.
How penetration testing differs from scanning
Vulnerability scanning answers the question "what in our surface looks known and outdated." A scanner compares service responses with a signature database, traverses hundreds of nodes in minutes, and returns a list—without context about what is actually reachable from outside.
It does not distinguish a test environment from a production perimeter, does not see that a login form is protected by a second factor, and does not connect findings with each other.
Manual testing begins where the signature ends.
The engineer works with business logic: can brute-forcing a reset code change another user's password, can a role restriction be bypassed by calling a method directly, does a chain from an open service, a weak account, and a reused secret lead to database access.
The methodological framework is set by OWASP, but the result is produced not by a checklist but by a hypothesis about a specific system and its data.
False positives are the main price of automation. A report of several hundred lines quickly stops being read, and real findings are lost along with it.
In manual testing, each hypothesis is either confirmed by a reproducible scenario or dismissed—the report retains what is exploitable and requires remediation.
The depth of testing also differs: a scanner reports a single vulnerability, while an engineer shows what data it leads to.
The frequency of testing also differs. It is reasonable to keep scanning in the release pipeline—it does not occupy engineers and catches hygiene regressions.
Penetration testing is launched for significant changes: a new external integration, a change in the role model, a perimeter migration, a major release.
In practice, they are combined—a regular background plus deep manual work on the target, with mandatory rechecking of closed findings.
Limitations and risks: what we clarify before starting work
Before starting, we document the test boundaries in writing: the list of addresses and services, the work window, exclusions, and stop rules.
Separately, we agree on the test mode—how aggressively the production environment can be affected, which scenarios are excluded (mass brute force, connection drops, data modification), and who on the client side has the right to stop work with one call.
The impact on the production environment is usually limited to a low-load window and an intensity limit, and for nodes without spare capacity we agree on a copy of the perimeter.
Report confidentiality and access to results are part of the contract: the circle of persons, a secure transfer channel, storage period, and a non-disclosure note.
Will the test bring down a production service?
We monitor metrics during the work: response time and error rate. If agreed thresholds are exceeded, work stops, the state is recorded, and changes are rolled back. We account for the risk of degradation in advance—then the test does not turn into unplanned downtime.
What to do with findings that cannot be closed immediately?
We divide them into two groups. The first are closed by configuration or an update in the nearest release.
The second require architecture rework or an update from an external vendor—until remediation, we select compensating measures: a filtering rule, access restriction, additional input control.
Who can access the test results?
We deliver the report to a limited circle of persons via a secure channel and store it in a closed repository with an access log.
For management, we prepare an executive summary without exploitation details—it does not provide a ready attack scenario if it ends up in the wrong hands.
Let's discuss the task: what is needed for an estimate and plan
The more accurate the input data, the fewer assumptions in the scope estimate—and the fewer surprises during the work.
We begin by discussing the task: which perimeters fall within the penetration test, what has already been tested before, and which results we inherit so as not to duplicate closed findings.
To come back with a work plan rather than follow-up questions, the following minimum is needed:
- Perimeter diagram: what we consider the external perimeter, what is internal, and whether there are intermediate environments.
- Service composition: web interfaces, software interfaces, admin panels, mobile clients, integrations with contractors.
- Time constraints: available work windows, peak load periods, prohibited hours.
- Decision owner: who approves the scope, who confirms findings, who issues access.
- Points of contact: the on-call engineer on your side and our lead specialist, an agreed communication channel.
- Existing artifacts: past reports, policies, incident response procedures.
- Acceptable boundaries: what is allowed and what we exclude—social engineering, physical access, load scenarios.
If some data is not yet available, that is not a stop: we will clarify in conversation and record assumptions directly in the plan. As a result, you receive the stages, their duration in weeks, the report composition, and what will be required from your team at each step.