Common Findings, Attack Chains, and How to Fix Them
6 MIN Read
After years of breaking into IAM environments, here’s what I find almost every single time.
INTRODUCTION
Introduction
Penetration testing is one of the most direct forms of feedback a security program can receive. Unlike audits, which assess documentation and configuration against a standard, a penetration test answers a fundamentally different question: Can an attacker actually exploit what exists in your environment?
Identity and Access Management environments are among the most consistently productive areas for penetration testers. Not because organizations are careless, but because the complexity of managing identity at scale creates exploitable gaps that governance reviews and automated scanning routinely miss.
This article draws on offensive security experience to describe the most common IAM findings uncovered during penetration tests, explains how attackers chain these findings into material impact, and provides remediation guidance for each category.
02 / IDENTITY & ACCESS MANAGEMENT
Finding 1: Misconfigured Roles and Excessive Entitlements
This is the most common finding across virtually every engagement. In cloud environments — particularly AWS, Azure, and GCP — IAM roles and permission policies are frequently misconfigured in ways that grant far more access than intended.
Common patterns include:
- Wildcard permissions (e.g., s3:* or Action: *) that grant access to all actions on a resource class
- Roles with administrator-equivalent permissions applied to non-administrative workloads
- Trust policies that allow role assumption from unintended principals, including overly permissive cross-account trusts
- IAM policies that have never been reviewed since initial configuration
Remediation: Conduct a full IAM policy review against the principle of least privilege. Use cloud-native tools and third-party solutions to identify unused permissions and right-size policies. Implement permission boundaries to limit the maximum permissions any role can hold.
03 / IDENTITY & ACCESS MANAGEMENT
Finding 2: Service Accounts with Excessive and Persistent Privileges
Service accounts are a persistent finding in nearly every assessment. In on-premises environments, service accounts are often members of high-privilege groups such as Domain Admins — a configuration that may have been made years ago for convenience and never revisited.
In cloud environments, managed identities and service principals regularly have permissions that far exceed what the associated application requires. And unlike human accounts, service accounts typically do not have MFA enforced and may have passwords that have not been rotated in years.
From an attacker’s perspective, a service account is an ideal target: it has high privileges, weak authentication controls, and its activity often blends into legitimate operational traffic.
Remediation: Implement a service account inventory and classification process. Enforce the principle of least privilege for all service accounts. Enroll service accounts in PAM tools where feasible, and implement monitoring for service account activity that deviates from established behavioral baselines.
04 / IDENTITY & ACCESS MANAGEMENT
Finding 3: Weak or Bypassable MFA Enforcement
Multi-factor authentication is a critical control, but its effectiveness depends entirely on how it is enforced. During penetration tests, MFA gaps appear frequently in predictable forms:
- Legacy authentication protocols (Basic Auth, NTLM, legacy SMTP/IMAP) that bypass modern MFA enforcement
- Conditional access policies with gaps that allow authentication from unmanaged devices or specific network ranges without MFA
- Applications integrated via federation that were configured before MFA enforcement policies existed
- Break-glass accounts with no MFA enrollment
- MFA methods susceptible to real-time phishing proxy attacks (SMS OTP, push notifications without number matching)
Remediation: Disable legacy authentication protocols where they are not operationally required. Audit conditional access policies for gaps in MFA enforcement. Prioritize migration to phishing-resistant MFA methods. Ensure break-glass accounts are subject to strong compensating controls including alerting on every use.
05 / IDENTITY & ACCESS MANAGEMENT
Finding 4: Privilege Escalation Paths
Privilege escalation findings are often the most impactful discoveries in an IAM assessment. An attacker who begins with a low-privilege foothold can, in many environments, escalate to domain administrator or cloud tenant administrator through a chain of misconfigured permissions.
Common escalation paths include:
- Users with permission to modify IAM policies or assign roles — allowing them to grant themselves additional permissions
- Misconfigured delegated administration in Active Directory, where a user has write access to the attributes of a high-privilege group
- Cloud IAM configurations where a service principal can attach policies to itself or to other principals
- Kerberoastable service accounts with weak passwords and high-privilege group memberships
- ACL misconfigurations in Active Directory that allow write access to privileged objects
Remediation: Map privilege escalation paths in your IAM environment using purpose-built tools for both Active Directory and cloud environments. Treat the ability to modify IAM configurations as a privileged action subject to the same controls as direct administrative access. Regularly review and test delegation configurations.
06 / IDENTITY & ACCESS MANAGEMENT
How Attackers Chain These Findings
Individual IAM findings rarely produce catastrophic impact in isolation. The real risk emerges when findings are chained together. A realistic attack scenario illustrates the pattern:
- An attacker obtains initial access through a phishing email targeting a standard user account
- The user account has access to a cloud storage service where application configuration files are stored
- One of those configuration files contains a service account credential that was inadvertently committed to storage
- The service account has an overly broad IAM role with permissions to modify IAM policies
- The attacker uses the service account to assign an administrator role to a new identity they control
- The attacker now has persistent, privileged access to the cloud environment
Each individual finding — the misconfigured storage access, the credential exposure, the overly permissive service account role — may have been assessed as medium severity in isolation. Chained together, they represent a critical path to full environment compromise.
07 / IDENTITY & ACCESS MANAGEMENT
Using Pen Test Findings to Drive Program Maturity
Penetration test findings should not be treated as a list of tickets to remediate and close. They are diagnostic data about the maturity of your IAM program. High-frequency findings indicate systemic gaps, not individual misconfigurations.
A mature program uses pen test results to:
- Identify patterns that indicate process failures (e.g., service accounts consistently over-privileged suggests provisioning processes do not enforce least privilege)
- Prioritize roadmap investments based on the most commonly exploitable attack paths
- Measure improvement over time by tracking finding categories across successive assessments
- Drive cross-functional conversations with application owners, cloud teams, and HR about identity lifecycle management
KEY TAKEAWAYS
Key Takeaways
Recap: IAM misconfigurations are not edge cases — they are consistent, exploitable, and chainable into full compromise scenarios.
- Misconfigured roles, excessive service account privileges, and MFA gaps are the most common IAM pen test findings
- Individual findings become critical when chained together into a logical attack path
- Penetration testing provides diagnostic information about systemic IAM program gaps, not just point-in-time vulnerabilities
- Remediation should address root-cause process failures, not just individual misconfigurations
- Regular IAM-focused assessments are a necessary complement to automated scanning and compliance reviews
Security / Strategy / Trust
Security isn't just technology.
It's trust.
Exploring identity, security strategy, AI security, and the human side of cybersecurity.
