Overview
An internal test answers a question US boards ask after every ransomware headline: if one laptop falls, how far does the damage spread? We start from a foothold you provide, usually a VPN account or a small test device on your network, and map the routes to sensitive systems. Where card data is in scope we also test the segmentation around the cardholder data environment, as PCI DSS expects.
Once an attacker has any foothold inside, whether through a phished laptop, a compromised supplier or a reachable service, the question is how far they can go. An internal test answers that by starting from an assumed-breach position on your network and attempting to expand access the way an intruder would: harvesting credentials, abusing misconfiguration, and pivoting from one system to the next toward the data and systems that would actually hurt you to lose.
We look hard at the weaknesses that let movement happen quietly. Shared local administrator passwords, credentials cached in memory and files, services running with too much privilege, and overly trusting network paths all let an attacker escalate without raising an alarm. We also test your segmentation directly, checking whether the boundaries you believe separate sensitive zones from the general network actually hold when pushed.
The output is a narrative of attack paths, not just a scan of internal hosts. We show the steps from initial foothold to high-value target, score each finding with CVSS v4.0, and recommend fixes that break the chain at the cheapest point, often a configuration change that removes an entire class of movement. Where this engagement meets a segmentation requirement, we document the result in terms your auditor will accept.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Access setupWe agree a starting position, from a connected device to a standard user account.
- DiscoveryWe map reachable systems, services, shares and trust relationships.
- Credential & escalationWe harvest credentials and pursue local and network privilege escalation.
- Lateral movementWe pivot toward critical assets, recording each step of the path.
- Report & debriefAttack paths are documented, scored and explained with chain-breaking fixes.
What you receive
- Narrative of attack paths from foothold to critical assets
- Risk-rated findings with CVSS v4.0 scores
- Segmentation test results where in scope
- Chain-breaking remediation prioritized by cost and impact
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- PTES
- NIST SP 800-115
- MITRE ATT&CK
- PCI DSS segmentation testing
- CVSS v4.0
- CWE
- PCI DSS v4.0.1 Req. 11.4
- NIST SP 800-171
Frequently asked questions
How do we give you internal access?
Usually a device we connect to your network, a VPN profile, or a jump host, plus a standard user account for assumed-breach testing. We agree the exact starting position with you, since it shapes what the test demonstrates.
Should testing start with or without credentials?
Assumed-breach, with a standard user account, reflects how most real intrusions unfold and finds far more in the time available. A zero-credential start is useful for specific questions, and we can combine both; we recommend the right mix during scoping.
Can this satisfy a segmentation testing requirement?
Yes. Where your scope calls for segmentation testing, we design the engagement to probe the specific boundaries involved and document whether they hold, in language suited to an auditor reviewing that control.
Does an internal and external test cover PCI DSS Requirement 11.4?
It can, when scoped for it. PCI DSS v4.0.1 wants penetration tests from inside and outside the network every year and after significant changes, following a documented methodology, plus proof that segmentation holds. We aren't a QSA or ASV, so quarterly ASV scans and the assessment itself stay with those firms.
Can you test our US networks without traveling?
Network, Active Directory, cloud and Kubernetes testing run remotely through a VPN account, jump host or small test device you place on the network. Wireless and hardware work need someone near the equipment; tell us the sites at scoping and we'll say plainly whether and how we can cover them.