Internal Penetration Testing: Find Hidden Vulnerabilities Before Attackers Do

Most organizations spend the bulk of their security budget fortifying the perimeter with firewalls, intrusion detection systems, email gateways, and such. Yet the attacks that cause the most damage almost always originate from, or pass through, the inside of the network.

This article breaks down exactly how internal penetration testing works, what it costs, what you’ll receive at the end, and how to evaluate whether your current security posture can withstand a threat that’s already past the front door.

Get in touch

What is internal penetration testing and why does it matter

An internal penetration test simulates what happens after the breach. We start from inside your network perimeter, operating as a malicious insider or an attacker who has already compromised an endpoint through phishing, a supply chain attack, or stolen VPN credentials. The goal is to determine how far an adversary can move, what they can access, and how much damage they can inflict before anyone notices.

The difference between an internal penetration test and an external penetration test

Internal pen testing is fundamentally different from external penetration testing. External tests probe your internet-facing assets, such as web applications, DNS servers, and exposed services. They answer the question “Can someone get in?” Internal testing answers the harder question: “What happens when they do?”

The assumed breach model reflects how modern attacks actually work. Perimeter defenses will eventually fail, credentials will be phished, and a contractor’s laptop will be compromised. The question is more whether your internal security controls can contain them once they’re there rather than whether an attacker will get inside your network.

Most networks we test have surprisingly flat architectures. An attacker who compromises a single workstation can often reach domain admin credentials within hours because internal network security was designed for convenience, not containment. This means that segmentation is incomplete and service accounts have excessive privileges. Or, legacy systems run unpatched because “they’re only accessible internally.” That last assumption is the one that gets organizations into trouble.

The strategic benefits of an internal security audit

Vulnerability scanning tells you what’s missing a patch, but internal penetration testing tells you what an attacker can actually do with those missing patches, combined with every other weakness in your environment, chained together into a real attack path.

The distinction matters. A vulnerability scanner might flag a system as having a medium-severity CVE. Our testers might chain that same vulnerability with a misconfigured service account, a permissive firewall rule, and a weak Group Policy Object to achieve full domain compromise. Automated tools can’t reason about context, but people can.

Risk mitigation with real evidence

Board members and audit committees respond to demonstrated risk. When we show that a tester moved from a guest Wi-Fi segment to a database containing 2 million patient records in under four hours, the conversation about security investment changes.

Compliance validation

Frameworks like PCI DSS, HIPAA, and SOC 2 require or strongly recommend regular penetration testing. PCI DSS Requirement 11.3 specifically mandates internal penetration testing at least annually and after any significant infrastructure change. But compliance should be a byproduct instead of the driver. Tests performed purely to check a compliance box tend to be shallow and miss the vulnerabilities that actually matter.

Security control validation

You’ve invested in endpoint detection and response, SIEM, network monitoring. Are they working? Internal pen testing is one of the only ways to answer that honestly. We regularly encounter environments where the SOC team has no visibility into lateral movement because their detection rules were never tuned for internal traffic patterns.

Legacy system risk exposure

Digital transformation often means new cloud-native applications running alongside legacy systems that can’t be patched or easily replaced. Internal testing reveals how those legacy systems create attack paths into your modernized infrastructure.

Our proven internal penetration testing methodology

We follow a structured, multi-phase approach that balances thoroughness with safety. Production environments require careful handling, and our penetration testing methodology reflects that.

Phase 1: Scoping and planning

Before any testing begins, we work with your team to define clear objectives and rules of engagement. Which systems are in scope? Are there systems that must be excluded (medical devices, production databases, SCADA controllers)? What are the testing windows? Who gets notified if we find something essential at 2 AM?

This phase also establishes communication protocols. We designate points of contact on both sides and agree on escalation procedures. If we discover evidence of an active compromise during testing (which happens more often than you’d expect), we need a clear chain of communication.

Phase 2: Reconnaissance and discovery

We map the internal network to understand its topology, identify live hosts, enumerate services, and catalog assets. This includes Active Directory enumeration, DNS zone analysis, network share discovery, and identification of trust relationships between domains and forests.

This phase often reveals assets that your IT team didn’t know existed. Shadow IT deployments, forgotten test servers, decommissioned systems still connected to the network. These are the assets most likely to be unpatched and misconfigured.

Phase 3: Vulnerability analysis

With a complete picture of the environment, we identify potential security weaknesses (e.g., missing patches, weak configurations, exposed services, and protocol vulnerabilities). We correlate findings against the specific architecture to determine which vulnerabilities are exploitable in context, not just in theory.

Phase 4: Exploitation

This is where testing differs from scanning. We attempt to exploit identified vulnerabilities to gain unauthorized access. We perform lateral movement across network segments, escalate privileges from standard user to domain administrator, and attempt to access sensitive data stores.

Every action is logged and timestamped. If something breaks (which is rare when scoping is done properly), we can trace exactly what happened and when.

Phase 5: Post-exploitation and analysis

Once we’ve achieved our objectives, we assess the full impact. What data could we access? Could we maintain persistent access? Could we exfiltrate data without triggering alerts? This phase reveals the true business impact of the vulnerabilities we exploited.

Phase 6: Reporting and remediation support

We deliver a detailed report (more on this below) and walk your team through every finding. Instead of simply handing over a PDF and disappearing, we’re available for follow-up questions and can perform retesting after your team has implemented fixes.

Choosing your approach to internal pen tests: black, grey, and white box testing

The amount of information we receive before testing starts determines the testing model and shapes what we can find.

Black box testing

Black box testing gives us zero knowledge. We’re placed on the network with no credentials, network diagrams, or even any information about the environment. This simulates an attacker who has just gained physical access or compromised a single endpoint. It’s the most realistic simulation but also the most time-consuming, since we spend significant effort on reconnaissance that your team could simply provide.

Grey box testing

This type starts us with a standard user account and basic network information. This simulates the most common threat scenario: a compromised employee account, a malicious insider with normal privileges, or an attacker who has phished credentials. Most of our engagements use this model because it maximizes the depth of testing within a practical timeframe.

White box testing

White box testing gives us full access, with network diagrams, source code, admin credentials, and architecture documentation. This is about conducting the deepest possible security review of your architecture. White box testing finds the most vulnerabilities per hour of testing but doesn’t measure your detection and response capabilities.

The right approach depends on your goals. If you want to test your blue team’s detection capabilities, black box is appropriate. If you want to find and fix the maximum number of security weaknesses, white box delivers the most value per dollar spent. And if you need a balance of realism and coverage, grey box is usually the right call.

Common vulnerabilities that attackers exploit

After hundreds of internal assessments, certain patterns repeat across industries and organization sizes.

Active directory weaknesses

Active Directory is the backbone of most enterprise environments, and it’s almost always the primary target. Kerberoasting (extracting and cracking service account password hashes) succeeds in roughly three out of four engagements we run. The root cause is usually service accounts with weak passwords that haven’t been rotated in years, sometimes decades.

NTLM relay attacks exploit the fact that many environments still allow NTLM authentication when Kerberos is available. We capture NTLM authentication attempts and relay them to other systems to gain unauthorized access. It’s a well-known attack that’s still shockingly effective.

Weak Group Policy Objects create another reliable attack path. GPOs that store credentials in SYSVOL, or that grant excessive local admin rights, give us footholds on dozens of machines simultaneously.

Network and system misconfigurations

Flat network architectures often leave workstations, servers, and sensitive systems connected without meaningful segmentation. Default credentials on network appliances, printers, and management interfaces can give attackers an easy foothold, while outdated protocols like SNMP v1/v2 with default community strings and disabled SMB signing create further opportunities for compromise.

Individually, these issues may seem minor, but together they can create clear attack paths that allow an attacker to move from a low-privilege workstation towards your most sensitive data.

Insufficient patching

Legacy systems running Windows Server 2008 or 2012 without Extended Security Updates can leave organizations exposed to known vulnerabilities. Java applications locked to outdated versions may introduce remote code execution risks, while “internal-only” systems are often overlooked during patching cycles because they aren’t directly exposed to the internet.

We exploit these regularly to gain access and move deeper into an environment.

Credential and authentication issues

Password reuse across service accounts, identical local administrator passwords across workstations, and credentials stored in plaintext scripts, configuration files, or network shares can all create unnecessary security risks. Overprivileged service accounts are another common weakness, with some accounts granted domain administrator access despite only requiring permissions for a single database or application.

How to secure modern infrastructure with pen testing for cloud and hybrid environments

Most organizations we work with don’t have purely on-premises networks anymore. They’re running hybrid environments with workloads spread across on-premises data centers, AWS, Azure, GCP, or some combination. This changes the testing approach significantly.

Identifying cloud IAM and access control weaknesses

Cloud infrastructure introduces a different attack surface. IAM misconfigurations are the most common issue we find such as overly permissive IAM roles and policies or cross-account trust relationships that grant broader access than intended. We also find service principals with credentials that never expire.

In Azure, we frequently discover that Entra ID (formerly Azure AD) sync configurations create paths from on-premises Active Directory compromise to cloud tenant takeover.

Finding storage access issues before attackers do

Storage misconfigurations remain common. S3 buckets, Azure Blob containers, and GCS buckets are often configured with overly broad access policies, giving users or services more access than they require.

Even when these resources aren’t publicly exposed, excessive internal permissions can allow compromised accounts to access sensitive data that should be restricted to specific roles or teams.

Testing serverless and container security

Serverless functions and container orchestration platforms introduce vulnerabilities that traditional network testing doesn’t cover. For example, lambda functions with excessive permissions, Kubernetes clusters with permissive RBAC configurations, and container images running as root with access to the host node’s resources.

Assessing the connection points in hybrid environments

Our approach to hybrid environments tests the seams between on-premises and cloud infrastructure. These integration points (VPN tunnels, AD sync services, API gateways connecting legacy and cloud applications) are where we find the most dangerous misconfigurations, because they’re managed by different teams with different security assumptions.

How an actionable report takes you from findings to fixes

The deliverables from an engagement need to serve both your executive leadership and your technical remediation teams.

The executive summary quantifies business risk in terms leadership cares about. Not “we found 47 high-severity vulnerabilities” but “we achieved access to the financial reporting database containing unencrypted revenue data within 3 hours of initial access, without triggering any security alerts.” It includes a risk rating for the overall environment and a prioritized list of strategic recommendations.

The technical breakdown provides your IT and security teams with everything they need to reproduce and fix each finding. This includes the specific vulnerability, the systems affected, the tools and techniques used, evidence of exploitation (screenshots, command output, log excerpts), and step-by-step remediation guidance.

Every vulnerability receives a risk rating based on both likelihood of exploitation and business impact if exploited. A severe vulnerability on a system containing no sensitive data may be lower priority than a medium vulnerability that provides access to your crown jewels.

We also include an attack narrative that tells the full story of the engagement, from the sequence of actions that took us from initial network access to our final objectives. This narrative helps security teams understand how individual vulnerabilities chain together and where defensive controls failed to detect or prevent our activities.

Remediation isn’t just a list of patches to apply. We provide specific configuration changes, architectural recommendations, and detection rules your SOC team can implement. And we offer retesting to verify that fixes are effective.

What defines an expert pen testing partner?

Not all penetration testing providers are held to the same standard. Individual certifications tell you about a single consultant’s skills. They don’t tell you whether the organisation has consistent quality control, sound data handling practices, or the governance to protect your most sensitive systems during a test. The strongest indicator of quality is whether the organisation itself has been independently assessed against recognised industry standards.

AMR CyberSecurity – Part of Infinum is Infinum’s dedicated security practice that works with enterprise and regulated-sector clients where compliance obligations, sensitive data, and operational continuity mean that security testing must be both technically rigorous and operationally safe.

Our penetration testing engagements are backed by three independent accreditations that matter most when selecting a provider for internal network testing:

NCSC CHECK accreditation

NCSC CHECK accreditation is granted by the UK National Cyber Security Centre to organisations that have demonstrated they can perform penetration testing to government and critical national infrastructure (CNI) standards. CHECK-accredited providers are assessed on technical competence, methodology, data handling, and governance — not just individual tester qualifications. For organisations in regulated industries, government supply chains, or critical infrastructure, NCSC CHECK is the accreditation that provides the highest level of assurance.

CREST accreditation

CREST accreditation is the globally recognised standard for technical security testing. CREST-accredited organisations are subject to ongoing assessment of their testing methodology, quality assurance processes, and professional standards. It means your engagement is conducted by an organisation that has been independently verified — not just a provider that employs individuals with offensive security certifications.

CREST STAR certification

Simulated Targeted Attack and Response — is the most demanding accreditation in the UK penetration testing market. It covers advanced adversarial simulation engagements, where testers emulate the tactics, techniques, and procedures of real-world threat actors over extended timeframes. For organisations that want to go beyond standard penetration testing and understand whether they could withstand a determined, sophisticated adversary, STAR is the relevant benchmark.

Together, these accreditations cover the full spectrum of internal security testing — from structured compliance-driven assessments through to advanced threat simulation.

What this means in practice

Accreditations set the standard. Our testers meet it. Our consultants hold recognised offensive security qualifications including OSCP, CHECK CTL, CHECK CTM, and specialist certifications relevant to their area of expertise — Active Directory, cloud infrastructure, OT/SCADA, and application security.

We match consultants to environments rather than assigning whoever is available. If you’re securing Azure infrastructure, you work with someone who has tested Azure infrastructure extensively. If your environment includes legacy OT systems alongside modern cloud workloads, we build a team with expertise across both.

Every engagement includes a clearly defined scope, agreed rules of engagement, appropriate legal protections, and a report your technical and leadership teams can act on. You’ll also know how much of the assessment is performed manually versus through automated scanning — because if most findings come from automated tools, you’re paying for a penetration test but receiving a vulnerability scan.

Infinum also holds ISO 27001 and SOC 2 certification, and is a PCI DSS Qualified Security Assessor (QSA) Company — relevant for any organisation operating under PCI DSS compliance requirements, where internal penetration testing is mandated under Requirement 11.

Why it matters for your decision

When you commission an internal penetration test, you’re granting an external team access to your most sensitive systems. The question of who that team is — how they’re trained, how their work is governed, and what standards they’re held to — is not a secondary consideration. It’s the primary one.

The difference between a provider that holds NCSC CHECK and CREST accreditation and one that doesn’t isn’t just a logo on a website. It’s the difference between a team that has been independently assessed against the same standards applied to government and CNI security testing, and one that hasn’t.

Understanding pen test pricing and timelines

Pricing varies significantly based on scope and complexity. But we can be transparent about what drives the cost.

Network size and complexity

This is the primary factor. An environment with 200 endpoints, a single Active Directory domain, and flat network architecture takes less time to test than an environment with 5,000 endpoints, multiple forests with trust relationships, and segmented network zones.

Depth of testing

A grey box test takes less time than a black box test covering the same environment, because we’re not spending days on initial reconnaissance. White box testing takes more total hours but produces more findings.

Specialized infrastructure

Cloud and hybrid environments, OT/SCADA systems, medical devices, and custom applications all require specialized expertise and careful handling.

Typical timelines for an internal penetration test range from one to three weeks of active testing for a mid-sized enterprise environment, plus one to two weeks for reporting. Larger or more complex environments can extend to four to six weeks.

We scope every engagement individually after an initial consultation to understand your environment. We don’t use flat-rate pricing because it incentivizes providers to cut corners. The cost should reflect the actual work required to give you meaningful results.

One thing worth mentioning is that the cheapest engagement is almost never the best value. We’ve been brought in to re-test environments after a prior vendor produced a 10-page report from a week of “testing” that was clearly just automated scanning output. The client paid twice for what should have been done right the first time.

Take the first step to a more secure network with Infinum

Automated tools catch the obvious issues, such as misconfigurations, missing patches, or default credentials on known ports. They don’t reason about attack paths or chain a weak service account password with a misconfigured delegation setting and an unmonitored network segment to achieve domain compromise. That’s what skilled testers do.

Your internal network almost certainly contains vulnerabilities that your current security tools aren’t surfacing. Your tools may not be bad, but weaknesses still exist in the relationships between systems, in configuration decisions made years ago under different assumptions, and in the gaps between teams that manage different parts of your infrastructure.

Proactive security means finding those weaknesses before someone else does. We’ve built our practice around doing exactly that, with thorough, manual internal penetration testing that tells you what an attacker can actually accomplish in your environment.

If you’re planning a security assessment, preparing for a compliance audit, or integrating new digital infrastructure with legacy systems, reach out to us at Infinum for a consultation. We’ll discuss your specific environment, define the right scope and approach, and give you a clear picture of what the engagement will involve.