External and Internal Infrastructure

Network Penetration Testing

Expert manual testing against your perimeter and inside your network, from internet-facing exposure to Active Directory privilege escalation and lateral movement. Two different engagements answering two different questions.

Two Engagements, Not One

External and internal testing are not interchangeable

A lot of buyers ask for "a network pentest" and mean one of two very different things. External testing asks how far an attacker gets from the internet with no access. Internal testing assumes they already have a foothold, through a phished laptop or a compromised vendor, and asks what happens next. The second question is usually the one that produces uncomfortable answers, and it takes meaningfully more time to answer properly.

External Network

Testing from the position of an attacker on the internet with no credentials and no access. Maps what you are actually exposing, then tries to get through it.

  • Perimeter reconnaissance and attack surface mapping
  • Exposed service identification and exploitation
  • VPN, remote access, and gateway testing
  • Credential attacks against internet-facing authentication
  • Externally reachable web services and management interfaces
  • Egress filtering and outbound control validation

Internal Network

Testing from inside, assuming an attacker already has a foothold. Focused on how far that foothold can be escalated and how much of the environment it reaches.

  • Active Directory attack paths and domain privilege escalation
  • Kerberoasting, AS-REP roasting, and delegation abuse
  • Network segmentation and isolation validation
  • Lateral movement across hosts and trust boundaries
  • Local and domain privilege escalation on Windows and Linux
  • Credential harvesting, reuse, and password spraying
  • Deployment, patching, and management system abuse
  • Sensitive data discovery on internal shares

Most mature programs run both, often on a staggered schedule so each gets proper attention. If you are choosing one to start, the answer usually depends on what is driving the test: a customer security review or a fresh perimeter tends to point external, while an incident, a segmentation claim, or an Active Directory environment nobody has audited points internal. We work through that in scoping rather than selling you both by default.

From Our Own Engagement Data

What we actually find

These are the serious issues, the ones we rate critical or high, that come up most often across our network engagements, ranked by how frequently we report them. Not a generic vulnerability list. This is what our own findings data says, and it is a reasonable preview of what a test of your environment is likely to surface.

Inside the network

Most frequent critical and high findings

  1. 01Active Directory Certificate Services misconfigurations
  2. 02Credentials stored in plaintext where any user can read them
  3. 03LLMNR, NBNS, and mDNS enabled, allowing name resolution poisoning
  4. 04Weak domain password policy
  5. 05Default or absent credentials on internal services
  6. 06Sensitive data sitting in unsecured locations

On the perimeter

Most frequent critical and high findings

  1. 01Cross-site scripting in externally exposed applications
  2. 02Unsupported and end-of-life software still in service
  3. 03Sensitive information exposed to unauthenticated users
  4. 04Unrestricted file upload
  5. 05Server-side request forgery
  6. 06Personal data leaking through exposed log files

Two things worth noticing. Internally, the highest-impact findings are almost never a missing patch. They are configuration and credential hygiene, with Active Directory Certificate Services now the single most common serious issue we report. On the perimeter, the critical and high findings are mostly in the web services you are exposing rather than in the network stack itself, which is why an external network test and an application test often belong in the same conversation.

Proof, Not Claims

The techniques, published by the people who use them

Every firm claims Active Directory expertise. Here is ours in public, written by our own consultants about the attack paths they run on real engagements. Read it and judge for yourself before you talk to a salesperson.

More of our research lives on the TrustFoundry blog. The tooling behind these engagements is a mix of the standard kit, Nmap, BloodHound, Impacket, and CrackMapExec among others, and custom tooling our team writes when the standard kit does not fit the environment.

What You Get

Findings you can act on, and evidence you can show

Findings arrive in your portal as they are confirmed rather than in a single document at the end, so a domain-level issue found in week one does not sit in a tester's notes until the report is written. Each finding carries severity, business impact, reproduction steps, and remediation guidance specific enough for whoever owns the fix. Retests are part of the engagement, so once you remediate you get verification recorded against the same finding.

You do not have to take our word for the quality of the write-up either. Our sample external network report is published without a form, alongside application and cloud samples.

Testing to satisfy a specific framework? Network testing is usually the core of it. See PCI DSS Requirement 11.4 for internal, external, and segmentation obligations, or SOC 2 penetration testing for what auditors expect as evidence.

FAQ

Network penetration testing questions

What is the difference between internal and external network penetration testing?

External testing starts from the internet with no access and asks how far an attacker gets through your perimeter. Internal testing starts from inside, assuming an attacker already has a foothold through a phished laptop or a compromised vendor, and asks how far that foothold escalates. They answer different questions and internal engagements are typically larger, because Active Directory and lateral movement take longer to work through properly.

Do we need both?

Most mature programs run both, often staggered so each gets full attention. If you are starting with one, the driver usually decides: a customer security review or a newly changed perimeter points external, while an incident, a segmentation claim you need to prove, or an Active Directory environment nobody has audited points internal.

Is this the same as a vulnerability scan?

No. A scan enumerates known weaknesses from signatures. A penetration test exploits them, chains them together, and pivots. The findings that matter most on our internal engagements, such as Active Directory Certificate Services abuse or credential reuse across trust boundaries, are things a scanner does not surface because they require an attacker to reason about the environment.

Do you test Active Directory specifically?

Yes, and it is usually where internal engagements produce their highest-impact findings. That covers Kerberoasting and AS-REP roasting, delegation abuse, certificate services misconfiguration, domain password policy, and the escalation paths that turn one workstation into domain-wide access. Several of our published research posts walk through these techniques in detail.

How does internal testing work if your team is not in our office?

Internal testing needs some form of foothold in the environment, and there are several clean ways to arrange that depending on your setup. We work out the most practical option with you during scoping. For organizations in the Kansas City metro, on-site work is straightforward and carries no travel cost.

Does network testing satisfy PCI DSS or SOC 2?

It is usually the core of both. PCI DSS Requirement 11.4 explicitly calls for internal, external, and segmentation testing, and SOC 2 auditors generally expect a recent penetration test as evidence that monitoring and vulnerability management controls work. Our PCI and SOC 2 pages cover what each expects in detail.

Find out what a foothold actually gets someone

Tell us what your environment looks like and what prompted the test. We will scope external, internal, or both around that instead of quoting a package.