During an internal penetration test for a municipality, our testers discovered something the client almost certainly didn’t know was accessible: a section of the network containing concealed carry permit records. This included personal information and sensitive law enforcement data. It was the kind of records that, in the wrong hands, create serious safety risks for the individuals listed in them.
Nobody told us that area was off-limits. But nobody told us it was accessible either, because nobody knew it was. The segmentation that should have isolated that data from the rest of the network either wasn’t configured correctly or wasn’t configured at all. We found it while looking for what an attacker with internal access could access. And an attacker with internal access could reach quite a lot.
This finding isn’t unusual. What’s unusual is that it got found.
Why Internal Pen Testing Exists
An internal penetration test starts with the assumption that an attacker has already gained access to your network. That assumption matters because it reflects how most real breaches develop. An employee clicks a phishing link or a contractor’s credentials get compromised. Maybe someone tailgates through the front door and plugs into a network port. The perimeter fails in any number of ways, Â and then the question becomes: once someone is inside, how much can they reach?
The answer, in most organizations, is more than anyone would be ok with. Weak internal segmentation is one of the most consistently identified findings in internal penetration testing. Testers often find that once they compromise one machine or gain a foothold on the network, they can pivot from there to domain controllers, file servers, HR systems, financial databases, and other sensitive areas that were never intended to be accessible from that starting point.
This is called lateral movement. It comprises the techniques an attacker uses to navigate from their initial access point to other systems on the network. A flat network, one where different systems and departments aren’t meaningfully separated from each other, turns a limited initial compromise into a much larger problem. An attacker who gets in through a low-security workstation in one department shouldn’t be able to reach the payroll system, the server room, or, as in the municipality case, law enforcement-sensitive records. But in networks without proper segmentation, they often can.
The Scope Conversation and What It Leaves Out
Every internal penetration test has a defined scope. The scoping document specifies which systems, IP ranges, and areas of the network the testers are authorized to access and assess. We ask for all of this for legitimate reasons. Some systems genuinely can’t be touched during testing without disrupting operations. Some areas require special authorization that wasn’t obtained. Some clients want to focus their budget on specific segments of the network rather than the whole environment.
The challenge is that scope defines what testers are authorized to target, not what the network is connected to.
When a client limits the scope of an internal test, they’re often making decisions based on how they believe their network is organized. They identify the systems they want tested, describe the segments they’re concerned about, and specify areas they’d prefer the testers avoid. What they can’t always account for is whether those areas are properly isolated from the systems in scope. If the segmentation isn’t working, the boundaries they assumed existed don’t exist in the way they imagined.
In the municipality engagement, the concealed carry permit data wasn’t identified as off-limits. It also wasn’t identified as in-scope. It simply appeared accessible as our testers moved through the network. The client likely assumed that data was isolated in a separate segment with appropriate access controls. It wasn’t. And a narrower scope that excluded more of the network entirely might have meant our testers never reached that area and never discovered the exposure.
Unfortunately, limiting the scope can limit what you find. Sometimes the most important findings are in places nobody thought to include.
What Network Segmentation Is Supposed to Do
Proper network segmentation divides an organization’s internal network into separate zones, sometimes called segments or VLANs, with controlled access between them. The idea is that systems and data with different sensitivity levels, different functions, and different user populations shouldn’t all live on the same flat network where everything can talk to everything else.
Segmentation limits how far an attacker can move once inside. Even when someone gets in, like through a phishing attack, a compromised credential, or any other initial access method, proper segmentation means the damage they can do is bounded by what that segment can reach. It turns a potentially catastrophic breach into a more contained incident.
When segmentation isn’t configured correctly, that containment disappears. The network behaves like a flat environment regardless of how it was designed on paper, and an attacker with access to any part of it potentially has access to all of it. Testers often find that once they compromise one machine, they can pivot to a domain controller and reach sensitive records. That pivot chain, from a low-privilege starting point to systems that should have been out of reach, is the real story that a strong internal penetration test report tells.
Not sure whether your network segmentation is working? Most organizations find out it isn’t when a tester tells them, or when an attacker doesn’t. Talk to MainNerve about what an internal test would find in your environment.
The Problem with Assuming Segmentation Is Working
Most organizations that have network segmentation believe it’s functioning correctly. It was set up at some point, it hasn’t generated obvious complaints, and the IT team is confident that sensitive systems are isolated from general access. That confidence is reasonable, but often wrong.
Network configurations change because systems get added. VLANs get modified during infrastructure upgrades. Firewall rules accumulate over years of incremental changes, with older rules that were intended to be temporary becoming permanent fixtures that nobody remembers adding. Cloud integrations create new pathways into the internal network that didn’t exist when the segmentation was originally designed. A misconfigured switch or router can effectively flatten a network that was supposed to be segmented.
The only reliable way to know whether your segmentation is working is to test it. Reviewing the configuration documents or asking the team that set it up won’t help. You have to actually attempt to reach systems that should be unreachable from a given starting point and verify whether those controls hold.
This is something we specifically look for during internal penetration tests. The municipality finding is a direct example of why that validation matters. The segmentation that should have isolated the concealed carry permit data wasn’t providing the protection anyone assumed it was.
What Scope Decisions Mean for Your Risk
When organizations limit the scope of an internal penetration test, they’re making a tradeoff, and it’s worth being clear-eyed about what that tradeoff involves.
A narrower scope tests fewer systems, costs less, and causes less concern about disrupting operations. It also means that vulnerabilities outside the scope aren’t found. If the network isn’t properly segmented, those areas may be reachable from the systems that were tested, which means the exposure exists whether or not the test covered it.
There are situations where limiting scope is the right call. A genuinely fragile legacy system that can’t tolerate testing or a segment with specific legal or regulatory restrictions on access. Perhaps a phased approach where budget constraints make full-scope testing impractical in a single engagement. These are legitimate reasons to define a narrower scope.
The important thing is understanding what a limited scope means in the context of your specific network. If your network is well-segmented and the areas outside the scope are genuinely isolated from the systems being tested, a limited scope is a reasonable and practical decision. If your network is flat or your segmentation hasn’t been verified recently, limiting the scope may mean the most significant vulnerabilities never surface because testing never reaches the areas where they live.
The conversation we try to have with every client during scoping is exactly this one: what do you know about how your network is segmented, which areas you’re confident are genuinely isolated, and what’s your goal for this engagement? Those answers shape whether a limited scope makes sense for their situation or whether testing more of the network would reveal things they need to know.
What the Municipality Finding Means
The concealed carry permit finding matters for reasons that go beyond the immediate security exposure, though that exposure alone is serious. Records identifying individuals who hold concealed carry permits are sensitive for obvious reasons. Exposure could create safety risks for permit holders, could be exploited for targeted harassment, and represents exactly the kind of data that law enforcement agencies handle under strict regulatory expectations.
But the finding also matters because nobody knew it was there. The client didn’t know that segment was accessible from the network we were testing. We didn’t know it existed before we found it. It surfaced because our testers were doing what internal penetration testers are supposed to do: following access wherever the network allowed, and documenting what they found.
An attacker operating on the same network would have found it too. The difference is what they would have done with it.
This is the argument for allowing testing to follow the network rather than constraining it to a predefined list of systems. Real attackers aren’t bound by scope documents. They move through whatever the network allows them to access, and they’re specifically looking for the sensitive data that’s worth taking. A test that mirrors that behavior, within appropriate ethical and legal boundaries, with client authorization, is more likely to surface the findings that matter than one that tests only the systems the client already suspected were at risk.
That doesn’t mean every internal test should be unlimited in scope. It means that scope decisions should be made with a clear understanding of what they include and what they leave uncovered, and, ideally, with some knowledge of whether the areas outside the scope are, in fact, isolated from those inside it.
Want to understand what a more comprehensive internal test would find in your environment? MainNerve has been conducting internal network penetration tests for over 20 years, including in municipal, healthcare, and financial environments where sensitive data requires careful handling. Start the conversation here.
Questions Worth Asking Before Your Next Internal Test
If you’re planning an internal penetration test, or evaluating whether the scope of a past engagement was adequate, these are the questions that will help you get the most useful result.
When was your network segmentation last verified? Not reviewed, but tested by someone attempting to cross segment boundaries from a position of limited access. Configuration review and functional verification are different, and only one tells you whether the controls work.
Are there areas of your network that hold particularly sensitive data, such as HR records, financial systems, customer data, law enforcement information, and health records? And do you know for certain that those areas are isolated from general-access network segments? If the answer to the second part is “I assume so” rather than “yes, we’ve tested it,” that’s a gap worth addressing.
Does your scope decision reflect a genuine understanding of what’s isolated versus what’s simply assumed to be isolated? If the answer is that scope was limited primarily for budget or convenience reasons without a thorough understanding of network topology, there may be more risk outside that scope than anyone has accounted for.
And finally, if an attacker got into your network today through the most likely initial access path, like a phishing email, a compromised credential, or a remote access vulnerability, where could they go from there? Which systems and data would be accessible before any detection or response occurred? That question is what an internal penetration test is designed to answer. How completely it answers it depends significantly on how the scope was defined.
At MainNerve, we’ve been conducting internal network penetration tests for over 20 years across a wide range of industries and environments, including public sector organizations where sensitive data carries serious regulatory and safety implications. We’re glad to help you think through what an internal test should cover in your specific environment. Set up your free consult today.
