Offensive Security

Network Penetration Testing

External perimeter and internal network, from the first exposed port to domain-wide privilege. Segmentation crossed to prove it, not read off a diagram.

Two questions decide a network's exposure: what an outsider can reach with no account, and how far one compromised laptop gets on the inside. The perimeter is rarely the inventory you think it is, and internal networks tend to trust themselves. A single set of cached credentials, an unpatched service, or a flat segment is often all it takes to move from a foothold to the domain.

We start where an attacker starts and keep going until we can show how far it reaches. Externally, that means the hosts and services actually exposed, including the ones outside your asset list. Internally, from an assumed-breach position, it means the path from one foothold through shares, credentials in memory and Active Directory to what you care about. Segmentation is tested by crossing it, so a boundary that holds comes with evidence that it holds.

Usually, one of these is true

An audit or a customer wants a recent network penetration test covering both your perimeter and your internal network.
You have merged, moved office, adopted a hybrid setup, or migrated to a new subnet, and no one has tested what it now exposes.
You believe your network is segmented, for PCI DSS or otherwise, and you need that boundary tested rather than assumed.
A phishing exercise or an incident showed that one workstation could reach far more than it should, and you want the internal blast radius mapped.

What we test

We scope to your external ranges, your internal segments, or both. Internal testing runs from an assumed-breach position, a standard workstation or a foothold on your network, because that is where real intrusions begin.

External perimeter. Every host, port and service actually reachable from the internet, including forgotten hosts and shadow assets outside the inventory.
Internal and lateral movement. What one foothold reaches: shares, services, credentials left in memory, and the hosts that trust each other.
Active Directory. Enumeration, delegation, ACL and Kerberos abuse, and the identity routes to domain-wide privilege.
Segmentation. VLAN and firewall boundaries tested by trying to cross them, so the result is evidence rather than a diagram.
Remote access. Wireless, VPN and remote-access paths, MFA coverage, and what a single stolen credential still opens.
Credentials and services. Password policy as it behaves, reused and cached credentials, default and weak service configuration, and secrets crossing the network in the clear.

How the test runs

Five stages, agreed in writing before anything starts. One named engineer, one shared channel, findings as they are confirmed.

Scope. We agree external ranges, internal segments, the starting position, engagement goals and an abort path in writing, then sign rules of engagement.
Map. We enumerate what is actually reachable: live hosts, open ports, running services and, inside, the domain, its trusts and its shares, before touching any of it.
Test by hand. Manual exploitation and privilege escalation from the agreed starting point. Tooling finds the low-hanging fruit; the attack path is built and proven by hand.
Report live. Confirmed findings reach your channel with the reproduction as they land. Anything critical, such as domain compromise, is reported within the hour.
Retest. Once fixes ship we re-run the affected tests, confirm the path is closed, and issue a letter of attestation.

What you get

Attack path narrative. The route from entry point to objective, step by step, so you can see how findings chain rather than reading them as a flat list.
Findings report. Each issue with a working reproduction, the affected hosts, a CWE mapping and a CVSS v4.0 rating, written by the tester.
Executive summary. A short account of what was reachable and how far it went, for people who will not read the technical detail.
Remediation guidance. Fixes ordered by how much of the attack path they close, not an undifferentiated host-by-host list.
Retest and attestation. A second pass over the fixes and a letter of attestation for your customers and auditors, included in the engagement.

What we need from you

In-scope external IP ranges and domains, and the internal subnets in scope, with anything explicitly excluded listed.
For internal testing, network access: a VPN, a jump box, or a device we place on the network, plus a standard domain user account for the assumed-breach start.
A network diagram or high-level overview, so we can tell an intended boundary from a gap.
A named technical contact who can confirm ownership, clear locked accounts and answer questions while testing runs.
Written authorisation to test, including any hosts you do not own, and confirmation that denial-of-service is out of scope unless you ask for it.

What we can show you

Research, not only testing. 70+ CVEs published by our researchers, with research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense. That depth goes into finding the path others miss.
The tester writes the report. No account-manager layer and no junior bench. The engineer who built the attack path writes it up, so the chain is not flattened by a report writer.
The fix comes with the finding. One team runs testing, hardening and engineering, so a finding can become a fix without a hand-over, and the retest and attestation are part of the engagement.
Your name stays yours. Mutual NDA and PGP before anything is shared. Evidence stays encrypted and least-privilege, and is destroyed after the retest on request. Client names stay undisclosed.

Standards we work to

We structure the work against the public methodologies and frameworks your reviewers recognise, so findings map onto the framework you report into without translation.

PTES
NIST SP 800-115
MITRE ATT&CK
OSSTMM
CIS Benchmarks
CWE
CVSS v4.0

Common questions

What is the difference between the external and internal test?

The external test works from the internet with no account and asks what an outsider can reach and exploit on your perimeter. The internal test works from inside, from an assumed-breach position, and asks how far a single foothold spreads. Many teams buy both; we can run either on its own.

What do you mean by assumed breach?

Rather than spend the engagement getting a foothold, we start with one, a standard domain user account or a device on your network, and test what happens next. It reflects how real intrusions unfold, through phishing or a stolen laptop, and it gives more coverage of lateral movement and privilege escalation than starting from zero.

Do you need to be on site?

Usually no. Internal testing runs over a VPN, a jump box, or a small device we ship for you to plug in. On-site testing is an option where wireless or physical access is in scope, and we agree that during scoping.

Will this test our segmentation for PCI DSS?

Yes. We test segmentation by attempting to cross the boundaries you believe are in place, so you get evidence that a boundary holds or proof that it does not. We produce the testing and evidence an assessor needs; we do not issue the certification ourselves.

What happens if you gain domain admin or reach something critical?

We report it to your channel within the hour of confirming it, on the escalation path agreed at kickoff, with the reproduction attached. We do not act on the access beyond what is needed to prove impact, and we agree any further steps with you before taking them.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.