Case Study: Cloud Penetration Testing

Case Study: Cloud Penetration Testing

Cloud penetration testing should establish what a realistic attacker could achieve after obtaining a valid user context, not merely list configuration weaknesses. In modern Microsoft cloud environments, legitimate identity, management and developer functionality can provide powerful routes to reconnaissance, secret access and lateral movement when permissions and monitoring are not sufficiently constrained.

This case study outlines a ProCheckUp assessment for a large international organisation. The engagement combined external perimeter testing with controlled compromise simulation across a non-production Azure application estate, Microsoft Entra ID, developer workstations, source-code repositories and connected CI/CD services.

Overview

ProCheckUp was commissioned to assess how the customer’s Azure-hosted application environment and connected services would respond to both an external attacker and the compromise of a legitimate developer workstation or identity.

The assessment covered four linked scenarios:

• - External threat simulation against agreed public-facing assets
• - Compromised developer workstation, including local code and credential exposure
• - Compromised developer identity and lateral movement through cloud and repository services
• - CI/CD exposure and software supply-chain reconnaissance

The final report consolidated twenty distinct findings and validated three complete attack chains progressing from a single compromised developer context towards high-impact cloud access. Testing also examined whether the activity generated visible alerts across the customer’s identity, cloud-security and data-loss-prevention controls.

Engagement at a glance

• - Four realistic attacker scenarios covering perimeter, endpoint, identity, cloud, repositories and CI/CD
• - Testing performed from both on-network and off-network conditions
• - Native developer tooling used in place of specialist offensive tooling
• - Manual validation and two-stage technical quality assurance
• - Twenty final findings and three validated attack chains
• - No visible alert observed during the validated chain activity

Assessment boundary: this was an authorised compromise simulation. The validated attack paths demonstrate what the agreed test identity and workstation context could achieve; they are not evidence that an unauthorised real-world compromise had occurred.

Challenge

The assessment had to distinguish genuine security exposure from normal cloud-platform behaviour, operate within a deliberately restricted corporate endpoint and avoid over-generalising controls that behaved differently on and off the customer’s network.

Legitimate functionality could become attacker capability

Much of the observed access relied on expected Microsoft cloud functionality rather than a software exploit. Directory read permissions, management-plane enumeration, authenticated command-line access and repository functions can all be legitimate for developers. The security question was whether the compromised identity could use those capabilities to obtain knowledge or access beyond its business need.

The workstation constrained tools, but not the attack path

The test workstation blocked PowerShell, the Windows command shell, Python, SQLite tooling and removable storage. ProCheckUp therefore conducted reconnaissance, credential extraction and controlled exfiltration using approved developer capabilities such as Git Bash, Azure CLI and custom shell scripts. This reflected how an attacker could adapt to a locked-down endpoint without introducing conspicuous offensive software.

Network controls varied by service and access path

Some data-plane services were restricted by firewall or network rules, while management-plane enumeration, token-backed access and selected public service endpoints remained available. Findings therefore had to be validated separately under on-VPN and off-VPN conditions rather than assuming that one network result applied across the entire cloud estate.

Requirements

The engagement was structured around the following technical and operational requirements:

• - Enumerate and validate the agreed public cloud perimeter, including domains, APIs, storage endpoints and serverless functions
• - Simulate compromise of a developer workstation and assess local source code, cached credentials, cloud profiles and key material
• - Use a compromised standard developer identity to test lateral movement through Azure, Microsoft Entra ID, secret stores, storage, databases, messaging and application services
• - Assess repository and CI/CD exposure, including access from both the corporate network and an untrusted public network
• - Review identity attack paths including users, groups, applications, service principals and managed identities
• - Determine whether tokens, secrets, configuration values and subscription context could be recovered and used meaningfully
• - Test the effectiveness of network boundaries affecting selected cloud data-plane services
• - Observe detection and alerting across identity protection, cloud-security monitoring, conditional access and data-loss-prevention controls
• - Deliver immediate, medium-term and longer-term recommendations aligned to least privilege and defence in depth

Solution

ProCheckUp combined host-level access, native Azure tooling, authenticated cloud enumeration and targeted attack-path validation. The methodology prioritised realistic use of the compromised developer context over broad automated scanning.

The engagement followed four stages:

• 1. Map: establish the public attack surface, workstation constraints, identity context, cloud subscriptions, repositories and relevant trust boundaries.
• 2. Operate: work with the tools and permissions available to the standard developer user, using native command-line and developer functionality.
• 3. Validate: test whether discovered tokens, permissions, secrets and configuration values translated into meaningful access or lateral-movement opportunities.
• 4. Challenge: subject the evidence, severity and wording to technical QA, downgrading or reframing findings where impact had not been conclusively demonstrated.

Traditional offensive tooling was deliberately avoided. This demonstrated that the attack chains did not depend on malware-like utilities or administrative privilege: approved developer tools and the compromised user’s existing cloud access were sufficient.

Manual validation remained central. Where discovery did not prove a practical impact, the issue was retained as reconnaissance or hardening guidance rather than presented as a confirmed exploit. Testing was also repeated under different network conditions to separate controls that depended on location from those governed primarily by identity and token state.

Validated Attack Chains

The assessment identified three principal paths in which individually familiar weaknesses combined into materially greater compromise potential.

Attack Chain 1: Token exfiltration and persistent access — Critical

Cloud authentication cache files and related Windows credential material were recoverable from within the compromised user session. The same trust boundary included access and refresh tokens and additional credential stores associated with cloud and developer services.

No local privilege escalation or specialist credential-dumping toolkit was required. Exfiltration and replay of valid token material could allow access to continue outside the original workstation context and reduce the effectiveness of controls that trusted the authenticated identity.

Recommended response: revoke and reissue affected sessions and credentials, reduce local exposure of reusable authentication material, strengthen token-protection and conditional-access controls, and alert on token use from unexpected devices, networks or geographies.

Attack Chain 2: Secret-store compromise and lateral movement — Critical / High

The standard developer identity held excessive standing permissions across multiple cloud secret stores. ProCheckUp demonstrated access to dozens of sensitive values, including application credentials, database connection information, messaging keys and credentials for connected third-party services.

The resulting blast radius extended beyond one application boundary. Retrieved material created routes towards hundreds of database endpoints, cloud messaging infrastructure, identity services and external service providers.

Recommended response: rotate every exposed credential, restrict secret-store permissions to the minimum required actions and resources, replace standing developer access with controlled just-in-time workflows, and monitor unusual enumeration or bulk retrieval.

Attack Chain 3: Application configuration and supply-chain exposure — Critical / High

Application settings contained hardcoded storage credentials rather than references to a managed secret source. Serverless key material was also exposed in a way that placed encrypted master-key data and related decryption context within the same accessible configuration path.

This created a viable route towards recovering powerful application keys, invoking protected serverless functionality and potentially influencing code or services consumed by downstream systems. The assessment did not need to perform every possible downstream action to demonstrate that the prerequisite access path existed.

Recommended response: remove hardcoded credentials from application settings, use managed identities and controlled secret references, rotate affected storage and function keys, restrict deployment permissions and monitor changes to serverless code and configuration.

Cross-Cutting Findings

Absence of visible detection and alerting — Critical

No visible alert was observed during token recovery, bulk secret access, storage enumeration, database probing, repository access or off-network replay within the monitoring channels available to the assessment team. This amplified every attack chain because a real attacker could potentially progress without timely investigation.

Recommendation: design and test detections for abnormal token use, high-volume secret retrieval, unusual management-plane enumeration, public-network repository access, privileged configuration access and lateral movement between connected services.

Incomplete data-perimeter controls — Medium

Network restrictions correctly blocked some off-network data-plane access, demonstrating that parts of the architecture were segmented. However, other cloud services and repositories remained publicly reachable to the compromised identity, leaving identity permissions and token controls as the principal remaining boundary.

Recommendation: apply private connectivity or explicit network restrictions where operationally appropriate, but do not treat network location as a substitute for least privilege, token protection and detection.

Directory and repository exposure — High / Critical

The compromised identity could enumerate extensive organisational and cross-tenant directory metadata, increasing the value of the account for targeted phishing and identity reconnaissance. Infrastructure-as-code could also be cloned from an untrusted public network without a visible conditional-access challenge or alert.

Recommendation: review default directory visibility and guest representation, apply appropriate access conditions to sensitive repositories, minimise exposed infrastructure metadata and alert on access patterns inconsistent with normal developer behaviour.

Managed identity discovery — Informational after technical QA

Operationally descriptive managed identities were discoverable and provided useful reconnaissance context. The issue was downgraded because the assessment did not confirm access to privileged role assignments from the test account. It was therefore retained as a hardening observation rather than overstated as a standalone exploit path.

Recommendation: review identity naming, assignment scope and monitoring, while preserving managed identities as a preferred alternative to stored application credentials.

What the Controls Demonstrated

The engagement showed that several controls had useful but limited effects:

• - Endpoint restrictions reduced the available toolset, but approved developer tooling still supported the attack workflow
• - Some network controls blocked selected off-network data-plane requests
• - Technical QA successfully prevented reconnaissance-only observations from being overstated

It also showed where control layers did not combine effectively:

• - Standing identity permissions exposed resources unnecessary for routine development
• - Recoverable token and credential material weakened the workstation trust boundary
• - Hardcoded secrets and broadly accessible secret stores expanded the blast radius
• - Publicly reachable cloud and repository services remained usable by the compromised identity
• - Detection did not provide visible warning during the validated attack-chain activity

The central issue was therefore not the absence of every individual control. It was the failure of identity, secrets, network and monitoring controls to form a sufficiently restrictive and observable system around a compromised developer context.

Outcome

The engagement converted a complex cloud estate into a defensible view of attacker capability. It demonstrated that a standard, non-administrative developer identity could reach far beyond its apparent business role through a combination of token exposure, excessive standing permissions, accessible configuration and insufficient alerting.

The report identified a common systemic cause across the twenty findings: least privilege had not been enforced consistently across identity, secret management and network access. It also showed that remediation of isolated findings would be insufficient unless the customer improved detection of the complete attack path.

ProCheckUp provided prioritised actions covering credential containment, permission reduction, application-secret remediation, directory and repository governance, network-boundary validation and cloud monitoring.

Important publication boundary: the source material defines the risks and recommended remediation programme. It does not establish that every recommendation has subsequently been implemented or independently retested.

Remediation Priorities

Immediate containment

• - Revoke and reissue exposed tokens, application credentials, storage keys and connected-service secrets
• - Restrict secret-store List and Get permissions to explicitly approved identities and resources
• - Remove hardcoded credentials from application and serverless configuration
• - Review sensitive repository access from unmanaged or unexpected networks
• - Investigate available logs for activity matching the validated attack chains

Medium-term hardening

• - Replace standing privileges with just-in-time and approval-based access
• - Review Entra ID default visibility, guest exposure and application permissions
• - Strengthen conditional-access and token-risk controls for developer identities
• - Use managed identities and approved secret references wherever supported
• - Restrict public data-plane access and verify each service under on-network and off-network conditions

Longer-term assurance

• - Build central detection and response coverage around identity-led cloud attack paths
• - Use privileged or hardened access workstations for production-adjacent administration
• - Review repository and CI/CD trust boundaries as part of cloud architecture governance
• - Re-test complete attack chains rather than validating individual configuration changes in isolation
• - Repeat independent cloud compromise simulations after material identity, platform or network changes

The Core Security Lesson

A locked-down developer laptop is only one control boundary. It cannot compensate for reusable authentication material, excessive cloud permissions, accessible secrets, public service paths and insufficient detection.

In this engagement, the most consequential attacker actions followed legitimate platform routes. The compromised context did not need a novel software exploit to create high-impact risk; it used the same identity, command-line, management and repository functions available to an authorised developer.

The correct question is not simply:

“Can a developer workstation run offensive tools?”

It is:

“If a developer identity is compromised, how far can legitimate access travel, which controls will stop it and will the organisation detect the attempt?”

How ProCheckUp Helps

ProCheckUp’s cloud penetration testing services help organisations understand how identity, endpoints, cloud resources, repositories and deployment systems combine under realistic compromise conditions. Support can include:

• - Azure and multi-cloud penetration testing
• - External cloud attack-surface assessment
• - Compromised workstation and identity simulation
• - Microsoft Entra ID attack-path analysis
• - Token, secret-store and application-configuration review
• - Repository and CI/CD exposure assessment
• - On-network and off-network control validation
• - Cloud detection and alerting assessment
• - Consultant-led validation and technical QA
• - Remediation verification and attack-path retesting

Related services include Azure penetration testing, cloud penetration testing and GitHub credential discovery and validation.

Conclusion

This engagement demonstrated the value of testing the whole cloud compromise path rather than assessing endpoint, identity, network and application controls independently.

By reducing standing access, protecting tokens, removing hardcoded secrets, constraining public service paths and validating detection against realistic attacker behaviour, organisations can materially reduce the effect of a compromised developer context.

To discuss a cloud penetration test, Azure identity assessment or developer-compromise simulation, contact ProCheckUp.