Internal Penetration Testing: What Happens When an Attacker Is Already Inside Your Network

Your firewall is configured correctly. Your email gateway filters phishing attempts. Your web applications passed their last penetration test. Your external attack surface is hardened. Then an employee clicks a link they shouldn't have. Or a contractor's VPN credentials are found in a breach database. Or an attacker compromises a vendor's system that has network access to yours.

Now the attacker is inside your network. What happens next?

Internal penetration testing answers that question. It simulates an attacker who has already gained some level of internal access, whether through a compromised employee account, a successful phishing attack, physical access to an office, or a breached third-party connection, and tests how far they can go. Can they move from a standard workstation to the domain controller? Can they escalate from a regular user to domain administrator? Can they reach the finance database, the customer records, the intellectual property, the backup systems?

Most organisations invest heavily in perimeter defences. External penetration testing validates those defences. But perimeters get breached. Phishing succeeds. Credentials leak. Insiders go rogue. The question isn't whether someone will eventually get inside. The question is what they can do once they're there.

Internal penetration testing reveals the answer. And for most organisations, the answer is: far more than they expected.

This guide covers what internal penetration testing is, how it differs from external testing, what gets tested across your internal network and Active Directory, the methodology professional testers follow, common findings, a practical checklist, compliance requirements across US and Singapore, and how to choose a provider that delivers genuine internal security assurance.

What Is Internal Penetration Testing?

Internal penetration testing is a security assessment simulating an attacker who has achieved initial access to the internal network. Testers operate from inside the network perimeter, typically with the access level of a standard corporate user, and attempt to escalate privileges, move laterally between systems, access sensitive data, and compromise critical infrastructure.

Internal pentesting tests the security controls that matter after the perimeter has been breached: network segmentation, Active Directory security, privilege management, credential hygiene, internal application security, and detection and response capabilities.

What Internal Pentesting Assumes

Internal penetration testing typically begins with one of these starting positions.

Compromised employee workstation. The tester operates from a standard corporate workstation with domain user credentials, simulating an attacker who compromised an employee through phishing, malware, or credential theft. This is the most common starting position because it reflects the most common real-world breach scenario.

Network access without credentials. The tester connects to the internal network (simulating physical access or compromised network device) but has no valid credentials. Testing begins with network reconnaissance and attempts to capture or crack credentials.

‍Compromised contractor or vendor access. The tester operates with the access level typically granted to contractors or third-party vendors, testing whether limited external partner access can be escalated to broader internal compromise.

Each starting position tests different defensive layers. Organisations should discuss which scenario best reflects their threat model when scoping internal penetration testing engagements.

Internal vs External Penetration Testing

Internal and external penetration testing serve complementary purposes. Understanding the difference helps organisations allocate testing appropriately.

Why you need both:

External penetration testing without internal testing validates the front door while ignoring what happens if someone gets through. Internal penetration testing without external testing assumes breach without testing whether it's achievable from outside. Comprehensive security testing includes both perspectives.

For external testing details, see our external penetration testing guide. For comprehensive methodology, see our penetration testing methodology guide.

What Gets Tested in Internal Penetration Testing

Active Directory Security

Active Directory (AD) is the primary target in almost every internal penetration test. AD controls authentication, authorisation, group policies, and access to every domain-joined resource in the environment. Compromising AD typically means compromising everything.

‍What testers assess in AD pentesting:

Kerberoasting. Testers request Kerberos service tickets for accounts with Service Principal Names (SPNs) and attempt offline cracking. Service accounts running with domain admin privileges and weak passwords are a consistently exploitable finding. One cracked service account password can grant complete domain control.

AS-REP Roasting. Accounts configured without Kerberos pre-authentication enabled allow testers to request encrypted material for offline password cracking without even needing valid credentials.

Pass-the-Hash and Pass-the-Ticket. Testers extract password hashes or Kerberos tickets from compromised systems and reuse them to authenticate to other systems without knowing the actual passwords. These attacks exploit how Windows authentication works at a protocol level.

Delegation abuse. Unconstrained and constrained delegation configurations allowing compromised systems to impersonate users to other services. Misconfigured delegation is a common path to domain administrator.

Group Policy abuse. Testers examine Group Policy Objects (GPOs) for credential exposure, insecure configurations pushed to domain machines, and GPO modification rights enabling policy manipulation.

Trust relationship exploitation. In multi-domain or multi-forest environments, trust relationships between domains create paths for lateral movement across security boundaries.

ACL/ACE abuse. Active Directory permissions (Access Control Entries) are analysed for excessive rights granting password reset capability, group membership modification, or DCSync privileges that shouldn't be broadly assigned.

DCSync attacks. Testers with sufficient AD permissions replicate the domain controller's password database, extracting every password hash in the domain.

Certificate Services (AD CS) abuse. Misconfigured Active Directory Certificate Services enable testers to request certificates for arbitrary users, including domain administrators, providing persistent elevated access.

Active Directory penetration testing consistently produces the highest-impact findings in internal assessments. Most organisations have AD misconfigurations enabling privilege escalation paths from standard user to domain administrator.

Lateral Movement Testing

Lateral movement testing evaluates whether an attacker who compromises one system can reach others across the network.

Network segmentation validation. Testers attempt to communicate between network segments that should be isolated: accessing production databases from office workstations, reaching management interfaces from user networks, or connecting to critical infrastructure from standard VLANs. Flat networks without effective segmentation allow unrestricted lateral movement.

Protocol-based movement. Testers use SMB, WMI, WinRM, RDP, SSH, and other protocols to move between systems using captured credentials, hashes, or tickets. Each accessible system provides new credentials and attack opportunities.

Credential harvesting. Compromised systems are searched for credentials in memory (using tools like Mimikatz), cached credentials, saved passwords in browsers, credential files, scripts containing passwords, and configuration files with connection strings.

Pivoting through compromised hosts. Each compromised system serves as a launch point for attacking systems it can reach that the tester's original position couldn't access, extending reach progressively deeper into the network.

Privilege Escalation Testing

Privilege escalation testing validates whether an attacker with limited access can achieve administrative control.

Local privilege escalation. Testers attempt to escalate from standard user to local administrator on individual systems through unpatched local vulnerabilities, misconfigured services running as SYSTEM, insecure file permissions allowing DLL hijacking, weak service account permissions, unquoted service paths, and AlwaysInstallElevated policy settings.

Domain privilege escalation. Testers attempt to escalate from standard domain user to domain administrator through AD attack paths described above (Kerberoasting, delegation abuse, ACL exploitation, AD CS abuse).

The goal: demonstrating the complete escalation path from initial compromise (standard user on a workstation) to domain domination (full control of all systems, data, and infrastructure).

Internal Network Service Security

Internal network services frequently receive less security hardening than internet-facing systems because they're considered "internal only." Internal penetration testing validates whether this assumption is safe.

Internal web applications. Intranet sites, admin panels, internal tools, and management interfaces are tested for authentication weaknesses, authorisation flaws, injection vulnerabilities, and default credentials. Internal applications frequently lack the security investment applied to customer-facing systems.

Database security. Database servers (SQL Server, Oracle, PostgreSQL, MySQL) are tested for authentication weaknesses, excessive permissions, default credentials, and data exposure. Internal databases often contain the most sensitive organisational data.

File shares. Network file shares are assessed for excessive permissions allowing broad access to sensitive documents, credentials stored in files, and confidential data accessible to standard users.

Management interfaces. Server management (iLO, iDRAC, IPMI), network device management (switch/router/firewall consoles), and virtualisation management (vCenter, Hyper-V) are tested for access control, default credentials, and known vulnerabilities.

Print and peripherals. Network printers, multifunction devices, and other peripherals are tested for information disclosure, credential capture, and pivot opportunities into segments they bridge.

Credential Security Assessment

Internal penetration testing evaluates how well the organisation protects credentials throughout their lifecycle.

Password policy effectiveness. Testing validates whether password policies prevent crackable passwords. Testers capture hashes (through Kerberoasting, NTLM relay, or hash extraction) and attempt cracking against common wordlists and rule sets. Policies requiring complexity but allowing short passwords or common patterns are frequently defeated.

Credential storage. Scripts, configuration files, documentation, SharePoint sites, and other repositories are searched for stored credentials. Group Policy Preferences historically stored credentials in SYSVOL readable by any domain user.

Credential reuse. Testers check whether local administrator passwords are identical across multiple systems (enabling mass lateral movement from a single compromised credential).

Service account hygiene. Service accounts with excessive privileges, weak passwords, and no password rotation create persistent attack paths that internal penetration testing identifies.

Detection and Response Testing

Internal penetration testing optionally evaluates whether security monitoring detects testing activity.

SIEM detection. Does the SIEM generate alerts for reconnaissance scanning, credential brute-forcing, lateral movement, privilege escalation, and data exfiltration attempts?

EDR detection. Do endpoint detection and response tools identify attacker tools, suspicious process behaviour, and credential access attempts?

SOC response. If alerts fire, does the security operations team investigate and respond within acceptable timeframes?

Detection testing transforms internal penetration testing from purely offensive assessment into purple team validation of defensive capabilities.

Internal Penetration Testing Methodology

Phase 1: Scoping and Rules of Engagement

Define the starting position (compromised workstation, network access only, contractor access), target objectives (domain administrator, specific data, specific systems), testing boundaries (excluded systems, testing hours, escalation procedures), and whether detection testing is in scope.

Scoping should clarify whether testers may use the full range of attack techniques or whether certain methods (denial of service, account lockout, production data modification) are restricted.

Phase 2: Internal Reconnaissance

From the established starting position, testers map the internal environment. Reconnaissance includes Active Directory enumeration (users, groups, computers, trusts, GPOs, SPNs), network scanning identifying live hosts, open ports, and running services, service identification and version fingerprinting, file share enumeration discovering accessible resources, and internal DNS analysis revealing hostnames and service locations.

Reconnaissance tools include BloodHound/SharpHound for AD attack path mapping, Nmap for network discovery, CrackMapExec for service enumeration, PowerView for AD enumeration, and Responder for network protocol exploitation.

Phase 3: Vulnerability Identification

Based on reconnaissance, testers identify exploitable vulnerabilities across identified systems and services. Vulnerability identification covers missing patches on internal systems, misconfigured services and applications, weak or default credentials, Active Directory misconfigurations enabling attack paths, and network segmentation gaps allowing unintended access.

Phase 4: Exploitation and Lateral Movement

Testers exploit identified vulnerabilities, harvesting credentials and moving laterally through the network. Each compromised system provides new credentials, new network access, and new attack opportunities.

Exploitation follows realistic attack patterns. Compromise a workstation. Extract credentials. Use captured credentials to access additional systems. Find more credentials. Reach higher-value targets. Escalate privileges. Demonstrate impact.

Phase 5: Privilege Escalation

Testers escalate privileges toward domain administrator or equivalent access through AD attack paths, local privilege escalation, and credential abuse. The goal is demonstrating the complete path from initial access to maximum achievable impact.

Phase 6: Objective Demonstration

Once maximum access is achieved, testers demonstrate business impact. Depending on scope, this includes accessing sensitive data (customer records, financial information, intellectual property), demonstrating domain controller compromise, showing ability to modify critical systems, proving access to backup systems (demonstrating ransomware exposure), and documenting complete attack path from initial access to objective.

Phase 7: Reporting and Remediation

The internal pentest report documents the complete attack narrative: starting position, reconnaissance findings, exploitation chain, lateral movement path, privilege escalation steps, and achieved objectives. Each finding includes evidence, severity rating, and specific remediation guidance.

For reporting standards, see our penetration testing reports guide.

Internal Penetration Testing Checklist

Active Directory Security

• Kerberoasting: no service accounts with weak passwords and elevated privileges

• AS-REP Roasting: pre-authentication enabled on all accounts

• No unconstrained delegation on non-DC computers

• Constrained delegation properly scoped

• AD CS templates secured against privilege escalation

• DCSync permissions limited to domain controllers

• ACLs reviewed for excessive permissions (password reset, group modification)

• Trust relationships minimised and monitored

• LAPS deployed for local administrator password management

• Tiered administration model implemented (Tier 0/1/2)

Network Segmentation

• Critical systems isolated from user networks

• Management networks segmented from production

• Database servers not accessible from workstation VLANs

• Lateral movement between segments requires explicit firewall rules

• East-west traffic monitoring enabled

Credential Security

• Password policy enforcing 14+ characters with breach database checking

• Local administrator passwords unique per system (LAPS)

• Service account passwords complex and rotated

• No credentials stored in Group Policy Preferences, scripts, or files

• Privileged accounts not used for daily operations

• MFA enforced for privileged access

Internal Application Security

• Internal web applications require authentication

• Default credentials removed from all internal systems

• Administrative interfaces restricted by IP or network segment

• Database servers requiring strong authentication

Detection and Response

• SIEM monitoring internal network for reconnaissance activity

• EDR deployed across all endpoints

• Alerts configured for Kerberoasting, pass-the-hash, DCSync

• Lateral movement detection rules enabled

• Incident response tested for internal compromise scenarios

Common Findings in Internal Penetration Testing

Finding 1: Domain Compromise Through Kerberoasting

The single most common critical finding in internal penetration testing. Service accounts with SPNs running with domain admin or equivalent privileges use passwords crackable within hours. One cracked service account password grants complete domain control.

Frequency: Present in over 70% of internal penetration tests.

Finding 2: Flat Networks Enabling Unrestricted Lateral Movement

Networks without effective segmentation allow standard workstations to communicate directly with domain controllers, database servers, management interfaces, and other critical systems. An attacker compromising any single workstation can reach every system on the network.

Frequency: Common in mid-market organisations that grew without network architecture planning.

Finding 3: Credentials in File Shares and Scripts

Passwords, connection strings, API keys, and administrative credentials stored in readable file shares, PowerShell scripts, batch files, documentation, and SharePoint sites. Standard domain users frequently have read access to files containing privileged credentials.

Frequency: Present in most environments with legacy operational practices.

Finding 4: Missing LAPS Causing Credential Reuse

Local administrator passwords identical across all workstations and servers. Compromising one local admin password provides administrative access to every system using the same password. Microsoft's Local Administrator Password Solution (LAPS) addresses this but many organisations haven't deployed it.

Frequency: Common in environments that haven't completed LAPS deployment.

Finding 5: Insufficient Monitoring of Internal Activity

SIEM and EDR deployed but not configured to detect internal attack patterns. Kerberoasting, pass-the-hash, lateral movement, and DCSync go undetected during testing. Security teams discover the compromise only when testers demonstrate achieved access in the final report.

Frequency: Present in organisations with detection focused on perimeter rather than internal monitoring.

Finding 6: Overprivileged Service and Administrative Accounts

Service accounts running with domain admin privileges when standard user permissions would suffice. IT staff using domain admin accounts for daily operations including email and web browsing. Privileged accounts without MFA protection.

Frequency: Nearly universal across organisations without mature privilege management.

Compliance Requirements for Internal Penetration Testing

US Compliance

PCI DSS Requirement 11.3 mandates annual internal penetration testing of the cardholder data environment. Internal testing must validate segmentation between the CDE and the broader network. See our PCI DSS penetration testing guide.

SOC 2 Trust Services Criteria expect evidence that internal security controls prevent unauthorised access. Internal penetration testing validates that controls function under adversarial conditions. See how SOC 2 pentests support compliance.

HIPAA requires safeguards protecting ePHI from internal and external threats. Internal pentesting validates that network segmentation, access controls, and monitoring protect health information from internal compromise.

NYDFS 23 NYCRR 500 requires annual penetration testing for financial institutions including internal assessment.

Singapore Compliance

MAS TRM Guidelines mandate regular penetration testing including internal assessment of critical systems. MAS expects financial institutions to test internal networks, Active Directory environments, and lateral movement controls. MAS references CREST as a recognised professional body for testing quality.

PDPA requires reasonable security arrangements. Internal penetration testing validates that internal controls protecting personal data resist insider threat and post-breach attacker scenarios.

For comprehensive compliance mapping, see our penetration testing compliance guide.

When to Conduct Internal Penetration Testing

Annually at minimum for compliance with PCI DSS, SOC 2, MAS TRM, and other frameworks requiring internal testing.

After Active Directory changes including domain migrations, trust relationship modifications, new domain controller deployments, and Group Policy restructuring.

After network architecture changes including segmentation redesigns, new VLAN implementations, firewall rule modifications, and data centre migrations.

After deploying new internal applications that handle sensitive data or provide administrative functionality.

After security incidents involving internal compromise to validate that remediation prevents similar attack paths.

After deploying defensive controls (LAPS, EDR, tiered admin model) to validate that new controls actually prevent attacks they're designed to stop.

When onboarding third-party vendors with network access to validate that vendor segments are properly isolated.

For frequency guidance, see our guide on how often to do penetration testing.

Internal Penetration Testing Tools

Professional internal penetration testers use specialised tools for AD assessment, lateral movement, and credential exploitation.

‍Active Directory tools: BloodHound/SharpHound (AD attack path mapping and visualisation), PowerView (AD enumeration), Rubeus (Kerberos attacks), Impacket (protocol-level AD attacks), Certipy (AD CS exploitation), and ADFind (AD queries).

‍Credential tools: Mimikatz (credential extraction from Windows memory), Hashcat (offline password cracking), Responder (LLMNR/NBT-NS/MDNS poisoning for credential capture), and CrackMapExec (credential validation across multiple systems).

Lateral movement tools: PsExec and SMBExec (remote command execution), WMIExec (WMI-based lateral movement), Evil-WinRM (WinRM-based access), and SSH for Linux lateral movement.

General tools: Nmap (network scanning), Metasploit (exploitation framework), Burp Suite (internal web application testing), and Cobalt Strike (adversary simulation).

Tools are essential but expertise determines testing quality. An experienced internal pentester with five tools will find more than an inexperienced tester with fifty. Manual penetration testing skill matters far more than tool inventory.

How AppSecure Delivers Internal Penetration Testing

AppSecure provides comprehensive internal penetration testing that reveals the attack paths organisations don't know exist.

Active Directory Expertise

AppSecure's internal pentest team specialises in Active Directory penetration testing. Testers map complete AD attack paths through Kerberoasting, delegation abuse, ACL exploitation, AD CS attacks, and trust relationship abuse, revealing privilege escalation routes from standard user to domain administrator.

Complete Attack Path Demonstration

Internal penetration testing doesn't just list individual findings. AppSecure demonstrates the complete attack narrative: starting from an assumed compromised workstation, moving laterally through the network, escalating privileges through AD attack paths, and achieving domain compromise with full evidence chain.

Zero False Positives

Every finding is manually validated through exploitation. Every attack path is demonstrated with proof-of-concept evidence. Development and IT teams receive findings they can trust and act on immediately.

Detection Validation

When in scope, AppSecure evaluates whether your SIEM, EDR, and SOC detect testing activity. Detection testing transforms internal pentesting from purely offensive assessment into purple team validation of your defensive capabilities.

3-Week Delivery

Standard internal penetration testing engagements deliver within three weeks. 90-day post-delivery support includes remediation guidance for AD hardening, segmentation improvements, and credential management, plus complimentary retesting validating that fixes are effective.

Compliance Mapping

Reports map findings to PCI DSS, SOC 2, ISO 27001, HIPAA, MAS TRM, and PDPA. Compliance mapping enables straightforward regulatory reporting across US and Singapore requirements.

Comprehensive Security Services

Internal testing integrates with external penetration testing, web application testing, API testing, and cloud testing for comprehensive coverage. Red teaming services simulate end-to-end adversary campaigns testing the full kill chain from initial access through internal compromise.

Ready for internal penetration testing that reveals what happens after the perimeter breaks?

Contact AppSecure:

• Schedule Internal Penetration Testing
• Application Security Assessment
• Red Teaming Services

Frequently Asked Questions

1. What is internal penetration testing?

Internal penetration testing simulates an attacker who has already gained access to the internal network, whether through a compromised employee account, successful phishing, physical access, or breached third-party connection. Testers operate from inside the network attempting lateral movement between systems, privilege escalation toward domain administrator, Active Directory exploitation, credential harvesting, and access to sensitive data. Internal pentesting reveals what an attacker can achieve after the perimeter has been breached.

2. How does internal penetration testing differ from external?

External penetration testing simulates an attacker on the internet testing whether perimeter defences prevent initial access. Internal penetration testing simulates an attacker already inside the network testing how far they can move, what privileges they can gain, and what data they can reach. External testing answers whether someone can get in. Internal testing answers what happens after they do. Comprehensive security programmes include both because external defences eventually fail and internal controls must contain the resulting compromise.

3. What is Active Directory penetration testing?

Active Directory pentesting specifically evaluates the security of your AD environment, the identity backbone controlling authentication and authorisation across domain-joined systems. AD pentesting tests for Kerberoasting (cracking service account passwords), pass-the-hash and pass-the-ticket attacks, delegation abuse, ACL/ACE exploitation, AD Certificate Services misconfiguration, DCSync attacks, Group Policy abuse, and trust relationship exploitation. AD compromise typically means complete domain compromise, making AD pentesting the highest-impact component of internal assessment.

4. What are the most common internal penetration testing findings?

The most common findings include service accounts with weak passwords and domain admin privileges (Kerberoasting), flat networks without segmentation enabling unrestricted lateral movement, credentials stored in file shares and scripts, identical local admin passwords across systems (missing LAPS), insufficient detection of internal attack activity, overprivileged accounts used for daily operations, legacy protocols (LLMNR, NBT-NS) enabling credential capture, and unpatched internal systems with known vulnerabilities.

5. How long does internal penetration testing take?

Standard internal penetration testing engagements take two to three weeks. Week one covers scoping, reconnaissance, and AD enumeration. Week two focuses on exploitation, lateral movement, and privilege escalation. Week three covers impact demonstration, reporting, and delivery. Complex environments with multiple domains, extensive network segmentation, and broad scope may require additional time. The engagement should allow sufficient time for thorough manual testing rather than rushing through automated checks.

6. What compliance frameworks require internal penetration testing?

PCI DSS Requirement 11.3 mandates annual internal penetration testing of cardholder data environments. SOC 2 expects evidence of internal security control effectiveness. HIPAA requires internal threat assessment for healthcare environments. MAS TRM (Singapore) mandates internal testing for financial institutions. NYDFS 23 NYCRR 500 requires annual internal penetration testing for financial institutions. ISO 27001 requires regular internal security assessment.

7. What is the difference between internal penetration testing and a vulnerability scan?

Internal vulnerability scanning runs automated tools identifying known vulnerabilities on internal systems. Scanning provides breadth but doesn't validate exploitability, test Active Directory attack paths, demonstrate lateral movement, or chain findings into attack narratives. Internal penetration testing includes scanning as one component but adds manual exploitation, AD attack path testing, credential harvesting, lateral movement demonstration, and privilege escalation proving real-world impact. Scanning finds potential issues. Internal pentesting proves which issues enable domain compromise.

8. How should organisations prepare for internal penetration testing?

Prepare a standard domain-joined workstation or VPN connection for the testing team. Provide standard domain user credentials (not elevated access). Document network topology, IP ranges, and any excluded systems. Designate an internal contact for questions during testing. Inform your SOC team about testing to distinguish test activity from real incidents (or keep SOC uninformed if detection testing is in scope). Define whether production systems are in scope or whether testing should target non-production environments.

9. Can internal penetration testing disrupt business operations?

Professional internal penetration testing is designed to identify vulnerabilities without causing operational disruption. Testers use controlled techniques that validate exploitability without causing data loss, service outage, or permanent modification. Techniques like account lockout, denial of service, or production data modification are typically excluded through rules of engagement. Scoping establishes testing boundaries preventing unintended impact. Quality providers communicate proactively about any testing activity that could potentially affect operations.

10. How often should internal penetration testing be conducted?

Internal penetration testing should be conducted annually at minimum for compliance frameworks requiring it (PCI DSS, SOC 2, MAS TRM). Additional testing should follow Active Directory changes, network architecture modifications, new internal application deployments, security incidents involving internal compromise, and deployment of new defensive controls (LAPS, EDR, segmentation). Organisations with complex AD environments and high-value internal data benefit from semi-annual internal testing.