Internal Network Penetration Testing: What It Finds That an External Test Never Will
An external test asks whether someone can get in. An internal test asks how far they go once they are. The starting points, the attack path internal tests usually find, the fixes that break the most paths, and how to scope one.
Network Security
An external penetration test asks whether someone on the internet can get in. An internal test asks the question that decides how bad a breach becomes: once someone is inside, with one laptop or one stolen password, how far can they go? Here is what an internal network test looks at, the attack paths it usually finds, how to scope one, and which fixes break the most paths for the least effort.
In short. Internal tests start from a realistic foothold, usually an ordinary domain user on an ordinary workstation, and follow the chain of small weaknesses that leads to domain control or to the data that matters. The links in that chain are rarely exotic: name-resolution poisoning, service accounts with crackable passwords, shared local administrator passwords, certificate templates nobody reviewed, and a network that lets every machine talk to every other. Each link has a well-known fix, and fixing the cheapest few usually breaks most of the paths.
Two tests, two different questions
Most organisations test their perimeter regularly, and many stop there. That leaves the most important question unanswered, because the perimeter is not the only way in. Phishing, a compromised supplier connection, a stolen VPN password or an exploited edge device all put an attacker inside without touching the systems an external test looks at.
| External penetration test | Internal penetration test | |
|---|---|---|
| The question | Can someone on the internet get in? | Once someone is in, how far can they go? |
| Starting point | The internet, with no access | A foothold inside: a workstation, a network port, a VPN account |
| Typical findings | Exposed services, unpatched edge devices, weak remote access | Credential exposure, privilege escalation paths, flat networks, reachable sensitive data |
| What it simulates | An opportunistic attacker probing the perimeter | A phished employee, a malicious insider, or an attacker who already got past the perimeter |
| What it measures | How hard you are to enter | How big a breach becomes once it starts |
Both are worth doing. If you can only afford one this year and your perimeter has been tested recently, the internal test usually teaches you more, because almost every serious incident eventually becomes an internal problem.
Choosing the starting point
The starting point is the most important scoping decision, because it decides which threat you are measuring. Most engagements use one or two of these.
| Starting point | What the tester is given | The scenario it represents |
|---|---|---|
| Assumed breach | A standard domain account on a standard-build workstation | A phished employee. The most common and usually the most useful starting point. |
| Unauthenticated network access | A device plugged into a network port, with no credentials | A visitor, contractor or intruder with physical access |
| Remote access | A VPN or remote desktop account | A stolen remote-access credential |
| Guest or segmented network | Access to the guest Wi-Fi or a partner network segment | Whether segmentation actually holds |
| Compromised server | Access to a specific internet-facing server | An exploited web application or edge device |
Assumed breach is efficient because it does not spend days of a paid engagement trying to phish someone. The question of whether phishing works is better answered separately, by a phishing simulation. The internal test takes the foothold as given and spends its time on what happens next.
The attack path an internal test usually finds
Internal findings are best read as a chain rather than a list. Each step on its own may look minor; together they turn one ordinary account into control of the domain. These are the links that come up again and again in Windows-centric enterprise networks, with their MITRE ATT&CK identifiers so your SOC can map them.
Step 1 — Capture credentials from the network itself
When a Windows machine cannot resolve a name through DNS, it falls back to broadcast protocols such as LLMNR, NetBIOS name service and mDNS. A tester on the same network answers those broadcasts, and the victim sends its authentication attempt to the tester. The captured hash can be cracked offline or relayed to another server that does not require SMB or LDAP signing. ATT&CK tracks this as T1557.001, Name Resolution Poisoning and SMB Relay.
Step 2 — Request tickets for service accounts
Any domain user can request a Kerberos service ticket for an account that has a service principal name. Part of that ticket is encrypted with the service account's password, so it can be taken offline and cracked. Service accounts often have old, human-chosen passwords and broad privileges. This is Kerberoasting, T1558.003.
Step 3 — Abuse certificate templates
Where Active Directory Certificate Services is deployed, misconfigured templates can let an ordinary user request a certificate that authenticates as someone else, including a domain administrator. ATT&CK covers this under T1649, Steal or Forge Authentication Certificates. It is common because certificate templates are set up once and rarely reviewed.
Step 4 — Reuse credentials across machines
If the local administrator password is the same on many machines, one compromised machine unlocks all of them, and the password hash itself can often be used without cracking it. Administrators who log in to ordinary workstations leave credentials behind that the next step can collect.
Step 5 — Move freely across a flat network
If every workstation can reach every server, every management interface and every database, there is nothing to slow the path down. Hypervisor consoles, out-of-band management cards, backup servers and database listeners reachable from user subnets are frequent findings.
Step 6 — Find the data, not only the domain
Domain administrator is a milestone, not the goal. A good test goes on to show what the access reaches: file shares holding customer data or passwords in scripts, databases, backups, and the systems that would matter in a ransomware attack. That is what turns a technical finding into a business one.
Alongside the chain, internal tests usually find a long tail of individual issues: unpatched internal services, default credentials on printers and management cards, legacy protocols still enabled, and sensitive data in places nobody expected. They matter, but the chain is what the report should lead with.
The fixes that break the most paths
The value of reading findings as a chain is that you do not have to fix everything at once. Break the cheapest links first and most paths stop working. The mitigations below are the ones MITRE ATT&CK lists for these techniques, with the practical change behind each.
| Link in the chain | Fix | Effort |
|---|---|---|
| Name resolution poisoning (T1557.001) | Disable LLMNR, NetBIOS and mDNS through group policy where they are not needed (M1042), and require SMB signing so captured authentication cannot be relayed (M1037). Require LDAP signing and channel binding on domain controllers. | Low, after testing for legacy dependencies |
| Kerberoasting (T1558.003) | Use long service account passwords, ideally 25 characters or more, or group managed service accounts (M1027); prefer AES over RC4 for Kerberos (M1041); remove service accounts from highly privileged groups (M1026). | Low to medium, account by account |
| Certificate abuse (T1649) | Review every published certificate template: who can enrol, whether the requester can specify the subject, and which templates allow authentication. Remove or restrict the dangerous combinations. | Medium, needs PKI knowledge |
| Credential reuse | Unique, rotated local administrator passwords on every machine, and a tiered administration model so domain administrators never log in to workstations. | Medium |
| Flat network | Segment management interfaces, backups and databases away from user networks (M1030). Start with the systems whose compromise would be worst. | Medium to high, plan it in stages |
Our Active Directory hardening guide covers the identity fixes in more depth. Segmentation is usually the slowest change and the one that pays off most in a ransomware incident, because it decides how far encryption can spread.
Scoping an internal test
A good scope document answers these questions before testing starts. Leaving any of them open is how engagements stall or cause the outage everyone was worried about.
- Starting point and credentials. Which of the starting points above, and the account and machine the tester will use, ready on day one.
- Goal. "Find vulnerabilities" produces a list. "Show whether a phished user can reach the payment database" produces a decision. Goal-based scoping gives better reports.
- In-scope ranges and exclusions. Which subnets and domains are in scope, and which systems must not be touched, such as fragile operational technology or a production system with no failover.
- Permitted actions. Whether password cracking, relay attacks and changes to directory objects are allowed, and whether the tester may access live data to prove impact or should stop at proving access.
- Timing and contacts. Testing windows, a named contact who can be reached at any hour, and the procedure if the tester finds evidence of a real compromise.
- Whether the SOC knows. An announced test measures your exposure. An unannounced one also measures whether your monitoring notices, and is closer to a red team exercise. Both are valid; decide which you are buying.
Vulnerability scan, internal pentest or red team?
| Internal vulnerability scan | Internal penetration test | Red team | |
|---|---|---|---|
| Finds | Known vulnerabilities and missing patches, host by host | How weaknesses chain together into a path | Whether detection and response stop a determined attacker |
| Misses | Misconfigurations in identity and permissions, and any chain | How well the SOC detects, unless that is in scope | Breadth: it pursues one objective, not every weakness |
| Frequency | Continuous or monthly | At least annually and after major change | When the basics are in place |
| Best for | Hygiene | Understanding and reducing breach impact | Testing a mature security operation |
Our comparison of red teaming and penetration testing goes further into when each is the right choice.
What the report should contain
- The attack path as a narrative. Each step from foothold to objective, with the evidence for that step and how long it took.
- The root cause of each step. Not "obtained domain admin" but the specific setting, account or template that allowed it.
- A fix order. Which link to break first to stop the most paths, rather than a list sorted only by severity score.
- Detection opportunities. For each step, what your monitoring could have seen and whether it did. This is the part that makes the next attack harder to hide, and it feeds directly into detection engineering.
- The long tail, separately. Individual findings outside the main chain, prioritised on their own.
How often
At least once a year, and after any change that alters the internal trust model: a merger, a domain migration, a move to hybrid identity, a new remote-access solution or a large network redesign. A retest after remediation confirms the chain is actually broken. For Indian banks and NBFCs, RBI's 2026 Cybersecurity Directions set penetration testing at least once in 12 months for critical information systems, many of which sit on the internal network rather than at the edge.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is the difference between an internal and an external penetration test?
An external test starts from the internet and asks whether someone can get in. An internal test starts from a foothold inside, such as an ordinary user's workstation, and asks how far someone can go once they are in. The first measures how hard you are to enter; the second measures how big a breach becomes.
QWhat is an assumed breach test?
A test that starts from a realistic foothold, usually a standard domain account on a standard workstation, instead of spending time trying to break in. It represents a phished employee and spends the engagement on what an attacker could do next.
QWill an internal test disrupt our network?
It should not, if it is scoped properly. Fragile systems are excluded, disruptive techniques need explicit permission, testing windows are agreed, and there is a named contact available throughout. Most internal testing uses the same protocols ordinary users and administrators use every day.
QDo we need an internal test if we run vulnerability scans?
Yes. A scan finds known vulnerabilities host by host. It does not find misconfigured identity settings, crackable service account passwords or certificate templates, and it cannot show how small weaknesses chain together into control of the domain. That chain is what an internal test is for.
QWhat is LLMNR poisoning and how do we stop it?
When Windows cannot resolve a name through DNS it falls back to broadcast protocols such as LLMNR and NetBIOS. An attacker on the network answers, and the victim sends its authentication attempt to them. Disable these protocols through group policy where they are not needed, and require SMB signing so captured authentication cannot be relayed.
QWhat is Kerberoasting?
Any domain user can request a Kerberos service ticket for an account with a service principal name, and part of that ticket is encrypted with the account's password, so it can be cracked offline. The defence is long service account passwords, ideally 25 characters or more, or group managed service accounts, AES rather than RC4, and keeping service accounts out of privileged groups.
QShould our SOC be told about the test?
It depends on what you want to measure. An announced test measures your exposure. An unannounced test also measures whether monitoring notices and responds, which moves it towards a red team exercise. Either way, someone senior should know, so a real incident is not mistaken for the test or the test for a real incident.
QWe are mostly in the cloud. Is an internal test still relevant?
Usually, yes, but the shape changes. Hybrid identity, where on-premises Active Directory synchronises to a cloud directory, means internal identity weaknesses can reach the cloud. Where there is little on-premises infrastructure left, a cloud penetration test and a cloud identity review cover the equivalent ground.
QHow often should we run an internal penetration test?
At least annually, after any change to the internal trust model such as a merger, domain migration or move to hybrid identity, and as a retest after remediation to confirm the attack path is actually broken.
QWhat should we fix first after an internal test?
The cheapest link that breaks the most attack paths. That is often disabling broadcast name resolution, requiring SMB and LDAP signing, rotating weak service account passwords and making local administrator passwords unique. Segmentation is slower but pays off most in a ransomware incident.
Related reading
For the identity side in depth, see Active Directory hardening against modern attacks. For turning each step of an attack path into something your SOC can see, detection engineering: SIEM use cases that survive tuning. For when an internal test is not enough and you want to test detection and response too, the purple teaming guide.
About Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, with offensive testing at the centre of its work. Our consultants hold OSCP and CISSP, every finding we report is reproduced by hand, and a remediation retest is included once you have made the fixes.
What we can do for you:
- Internal and external network testing. Network penetration testing from the starting point that matches your threat, reported as attack paths with a fix order and detection opportunities for each step.
- The identity layer. An Active Directory security assessment covering service accounts, delegation, certificate templates and administrative tiering, and a cloud identity review where your directory reaches the cloud.
- Segmentation and wireless. A network architecture review to plan segmentation in stages, and wireless security testing to check that guest and corporate networks are really separate.
Sources
- MITRE ATT&CK, T1557.001 Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay, with mitigations M1042, M1037, M1031 and M1030.
- MITRE ATT&CK, T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting, with mitigations M1041, M1027 and M1026.
- MITRE ATT&CK, T1649 Steal or Forge Authentication Certificates.
- NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment.
Adayptus Consulting
Offensive Security, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, with offensive testing at the centre of its work across networks, applications and cloud.
On This Page
- Two tests, two different questions
- Choosing the starting point
- The attack path an internal test usually finds
- The fixes that break the most paths
- Scoping an internal test
- Vulnerability scan, internal pentest or red team?
- What the report should contain
- How often
- Frequently Asked Questions
- Related reading
- About Adayptus
- Sources
