Internal enterprise penetration testing
How far could an attacker get inside your enterprise?
We begin from an agreed identity, device or remote-access position, then follow the paths an attacker could take across your connected enterprise to the systems, data and privileges that matter most.
Surface
What could an attacker reach from inside?
An attacker inside your organisation does not see identity, endpoints, networks, applications and cloud as separate environments. Starting from an agreed account, device or remote-access position, we map how those parts connect and identify the critical systems, data and privileges that could be reached.
Surface
One connected enterprise
What could an attacker reach from inside?
One account, device or remote connection can expose routes across an organisation that appear separate from the outside.
Agreed starting access
An account, device or remote connection
We agree a credible internal position, then assess the identities, systems and services available from it.
Connected attack paths
Paths across the enterprise
Testing follows permissions and trusted connections across identity, endpoints, applications, networks, SaaS and cloud platforms.
People, identities and endpoints
The account, device, remote access and network services available from the agreed starting position.
Identity and access
Active Directory, Entra ID and other in-scope identity platforms, including their permissions, trust relationships and integrations.
Applications and platforms
Internal applications, SaaS, servers, databases and cloud platforms reachable through the access gained during testing.
Critical objectives
The systems, data and privileges agreed during scoping as the outcomes an attacker must be prevented from reaching.
Overview
What is internal enterprise penetration testing?
Internal enterprise penetration testing starts from an agreed position inside your environment and follows the routes available from it. We test how weaknesses across identity, endpoints, networks, applications and cloud services combine, then show which critical systems, data and privileges an attacker could reach.
This is for you if…
Your users rely on connected services
Staff use shared identities across on-premises systems, cloud platforms, SaaS applications and business data.
You have been asked for proof
A client, insurer or auditor asks for independent assurance across the connected enterprise.
Something inside has changed
A merger, new site, identity migration or cloud service has created new systems, integrations or access paths.
New to the term? What penetration testing means, in our glossary
Motive
What must an attacker never reach?
Before testing begins, we agree the business-critical outcomes an attacker must be prevented from achieving. These objectives might include taking control of privileged identities, reaching sensitive data, accessing critical applications or moving into cloud platforms. They give every path a clear destination and keep testing focused on business impact.
Privileged identity and admin access
Control of the identities and permissions that govern the enterprise
Financial or customer information
Sensitive files, records and databases used by the organisation
Critical business systems
HR, payroll, finance and other systems agreed as priorities
Restricted environments
Systems and network areas intended to remain isolated from ordinary users
Cloud platforms and services
AWS, Azure, Microsoft 365 and other in-scope cloud services
A route for taking data out
Approved routes that could allow sensitive information to leave the organisation
Reach
One compromised account opened the door to the entire cloud estate
Testing began with access to a compromised user account. A weakness in the organisation's internal identity environment allowed us to take control of the domain. That control extended through a trusted connection into AWS, where administrator access was available across every connected cloud account.
Anonymised assessment example
- Demonstrated
- Potential
Starting point
Testing began from a compromised user account
The engagement began with access to an agreed Active Directory user account.
Yields An authenticated position inside the organisation
Domain control
Kerberoasting led to Domain Admin
A Kerberoasting path exposed a route to Domain Admin and control of the directory.
Yields Full control of the Active Directory domain
Trusted cloud access
Cloud-linked groups opened access to AWS
Two Active Directory groups controlled access to the organisation's AWS portal.
Yields Trusted access to every connected AWS account
Demonstrated outcome
Administrator access was available across every AWS account
The portal listed every AWS account with the AdministratorAccess permission set available.
Verified by Adversify testers
Potential business impact
- Changes to cloud infrastructure and services
- Access to sensitive information held in AWS
- Persistent administrative access across accounts
In practice
A route that began with one internal user account ultimately made administrator access available across the organisation's AWS estate. The engagement showed how a weakness in one environment could cross a trusted boundary and create a much wider business risk.
Testing Active Directory and AWS separately could have missed the significance of that connection. Remediation addressed both the Kerberoasting path and the trust between Active Directory and AWS, particularly control of the groups that granted cloud access.
Methodology
How Adversify tests your internal enterprise
Each test has four stages: agree access and goals, map how systems connect, follow key attack paths and explain what must change. Testing crosses identity, devices, networks, applications and cloud services in scope when the access gained makes that possible.
- Networks
- Identity
- SaaS
- Endpoints
- Applications
- Data
- Cloud
Engagement design
We agree the systems, data and privileges that matter most, then choose starting access that reflects a credible position inside the organisation. This might be an account, managed device, remote connection or a combination of them.
- Objectives
- Starting position
- Rules of engagement
Map the connected enterprise
From that access, we map the identities, endpoints, reachable systems, applications, SaaS and cloud services available. Permissions, integrations and trusted connections reveal which routes are most relevant to the agreed objectives.
- Identity
- Reachability
- Connected services
Walk the paths
Our testers follow each relevant route by hand, using the access gained at one step to test the next. A path continues towards an agreed objective until it reaches that objective or an effective control stops further progress.
- Manual testing
- Privilege escalation
- Lateral movement
Reporting and evaluation
The Adversify report records the objectives, the paths we validated and the controls that stopped further progress. Each finding includes evidence and remediation guidance. During the debrief, the testers walk your teams through the routes and priorities.
- Report
- Debrief
- Recommendations
Coverage
What does an internal enterprise penetration test cover?
Coverage follows the connections available from the agreed starting access. We assess identities, endpoints, network boundaries, internal systems, stored secrets, SaaS and cloud platforms where they contribute to an attack path. The agreed objectives keep testing focused on what matters most.
Agreed starting access
The account, device, remote connection or other internal position agreed during scoping.
Identity and privileged access
Permissions, authentication and trust assessed across Active Directory, Entra ID and other in-scope identity platforms.
Endpoints and network boundaries
Devices, reachable systems and the controls intended to separate users, services and sensitive areas.
Credentials and stored secrets
Approved locations assessed for passwords, tokens, keys and other secrets that could open another route.
Business systems and data
Internal applications, file services, databases and servers assessed using the access gained during testing.
SaaS and cloud platforms
Trusted access, roles, management interfaces and connected services assessed across in-scope SaaS and cloud platforms.
What you get
What you get from an internal enterprise penetration test
Your report shows each validated attack path from the agreed starting access to the systems, data or privileges it reached. Findings include evidence and clear remediation guidance. Priorities reflect business impact and the routes each improvement would close, helping leadership teams decide what to address first.
You receive
The penetration test report
A clear summary for decision-makers and detailed findings for the teams responsible for the connected enterprise.
Evidence for every finding
Evidence and reproduction steps for each weakness across identity, endpoints, networks, applications, SaaS and cloud.
Validated attack paths
How each tested route developed from the agreed access, what it reached and where controls stopped further progress.
Remediation guidance
Improvements prioritised by business impact and by how many important attack paths each control would close.
A debrief with the testers
A walkthrough of the paths, findings and priorities with the people who performed the assessment.
What changes
- Scope reflects realistic internal access
- Each validated route is shown from start to impact
- Priorities reflect business risk and the paths each change would close
- Changes in the connected enterprise inform the next test
Internal estates change where identity, applications and cloud services connect. A new synchronisation rule, integration or relaxed access policy can reopen a route. Cloud Identity Assurance combines external monitoring with twice-yearly Microsoft 365 or Google Workspace reviews, helping you decide when to test again.
Questions
Internal enterprise penetration testing questions
Clients ask how starting access, scope, disruption and cloud services are handled. Before work begins, we agree these points with you, along with the goals, safeguards and boundaries that guide the engagement and keep each stage focused, safe and controlled.
Not answered here? Ask it on the scoping call
Is it scoped by host count or by enterprise?
By the agreed starting position, connected attack surface and objectives. A list of addresses does not show what a trusted identity and device can reach across on-premises, SaaS and cloud services. The quote names the access, systems and boundaries included in scope.
What access do you need from us?
We agree the starting access during scoping. It may include a corporate or cloud identity, a managed workstation, remote access or a combination of them. We do not require privileged access at the outset unless a particular scenario calls for it.
Will the testing disrupt our staff?
Not by design. We agree the testing window, the limits and a named contact before we start. Potentially disruptive actions are identified and discussed with you in advance, with agreed safeguards. If we reach something sensitive mid-test, we stop and call you.
Is the cloud included?
Where it is included in scope. Identity federation, synchronisation, role assignments, management interfaces and connected services can be assessed across Microsoft 365, Azure, AWS, GCP and other SaaS or cloud platforms. The quote states which services and access paths are covered.
Is a retest included?
No, a retest is not part of the internal test. Once the changes you make to the affected identities, systems and services are in, a retest to check them can be scoped and quoted separately.
How is this different from assumed breach testing?
Internal enterprise testing looks broadly for attack paths from agreed access across the connected environment. Assumed breach testing starts from one defined compromise and focuses more on whether security controls and teams identify and contain the activity.
What happens next?
Tell us what an attacker must never reach
Tell us which systems, data or privileges would matter most if a trusted account or device were compromised. A penetration tester will reply within one working hour, help define a representative starting position and scope the paths to those objectives. Deliverables are agreed in writing before testing begins.
- Scoped to your enterprise, agreed before we start
- CREST-accredited for penetration testing
- Based in York, working across the UK
A tester goes through the scope with you before anything is quoted.