top of page

Internal Network Penetration Testing

What is an internal network penetration test?

An internal network penetration test simulates what an attacker could do if they already had a foothold inside your network. That might be a compromised employee account, a phishing email that got through, a contractor's device, or a visitor who plugged something in. The question the test answers is: once someone is in, how far can they go?
 

This is a different question from whether your perimeter holds up. External testing looks at what an attacker can reach from the internet. Internal testing starts from the assumption that the perimeter has already been crossed which, for most organisations that have experienced an incident, is exactly what happened.
 

What we test

We approach an internal network test the way an attacker with initial access would, working through a realistic attack path rather than simply running a scanner across the network.
 

Network enumeration and mapping - identifying what systems, services and devices are reachable from a standard user position on the network, including things that should not be accessible from that position.

Privilege escalation - attempting to move from a low-privilege user account to a more powerful one, through misconfigured permissions, unpatched vulnerabilities, exposed service accounts, or credential material left accessible on the network.

Lateral movement - testing how easily access to one system can be used to reach others. In environments where credential reuse is common or where admin accounts are used for day-to-day work, this can happen quickly and silently.

Active Directory assessment - for organisations running Windows environments, Active Directory is the identity backbone of the network and a frequent target. We test for common misconfigurations and attack paths including Kerberoasting, AS-REP roasting, unconstrained delegation, and weak ACL permissions that can allow an attacker to escalate to domain administrator.

Credential exposure - checking whether password hashes, plaintext credentials or session tokens are accessible from a standard network position, including in file shares, scripts, configuration files and memory on accessible systems.

Network segmentation - testing whether sensitive parts of the network are properly isolated. If a standard workstation can reach finance systems, production servers or backup infrastructure directly, that is a finding regardless of whether those systems have their own vulnerabilities.

Detection capability - noting whether the activity we conduct during the test generates alerts or is visible in your logging. This is not a formal red team exercise, but we will flag obvious gaps in visibility where we find them.
 

Who needs an internal network penetration test?

Organisations that have never tested their internal network. Many businesses invest in perimeter security such as firewalls, email filtering, endpoint protection, etc. without ever testing what an attacker can do once those controls are bypassed. The internal network is often where the most sensitive data lives, and in our experience it is frequently less well-defended than the perimeter.
 

Compliance-driven testing. ISO 27001 requires organisations to assess the security of their internal environment as part of their information security management programme. If you are working toward certification or maintaining it, internal network testing is a natural part of that process. PCI DSS similarly requires internal penetration testing for organisations within scope, on at least an annual basis.
 

After a significant change. A network that has grown organically over several years tends to accumulate legacy systems, forgotten service accounts, over-permissioned groups and configuration drift. After a merger, a significant infrastructure change, or a move to a hybrid environment mixing on-premise and cloud, an internal test gives you a current picture of what the network actually looks like from an attacker's perspective.
 

Following an incident. If your organisation has experienced a breach or a near-miss, an internal penetration test carried out after remediation helps confirm that the attack path has been closed and that similar paths do not exist elsewhere.
 

What the process looks like

We start with a scoping call to understand your environment, the size of the network, the operating systems in use, whether you are running Active Directory, and whether there are any systems that need to be treated carefully during testing.
 

For most internal tests we are provided with a standard user account and network access, either on-site or via VPN. This represents a realistic starting position, a compromised employee account, a contractor with legitimate access, or a device that has been connected to the network.
 

Testing typically runs over three to five days depending on network size and complexity. We document our findings as we work, including the full attack path taken to reach each significant finding, so your team can understand not just what we found but how we got there.
 

The report includes a management summary written for non-technical readers, a full technical section for your IT team or infrastructure provider, and prioritised remediation guidance for each finding. We are available after delivery to walk through the results and answer questions.
 

Re-testing

Once remediation work has been completed, we offer a retest focused on the specific findings from the original engagement. This confirms that fixes have been applied correctly and that the attack paths we identified have been closed.
 

Based in Auckland, working across New Zealand

On-site testing can be arranged for Auckland businesses and we travel for engagements elsewhere in New Zealand where on-site access is needed. Many internal tests can also be conducted remotely via VPN, which works well for organisations with a single main office or a largely cloud-based environment.

bottom of page