How should security teams audit AWS default service roles before attackers abuse them for lateral movement?

Why This Matters for Security Teams

AWS default service roles are easy to overlook because they are created to make services work, not to make them safe. That convenience becomes dangerous when a role trusted by SageMaker, Glue, EMR, or another backend service can read broad S3 data, invoke unexpected APIs, or pass privilege into a different workload. Attackers do not need a perfect initial foothold if they can reuse a service role for lateral movement. Current guidance suggests treating these roles as production identities, not setup artefacts.

The practical risk is that default breadth often remains invisible until a compromise is already under way. Teams reviewing only human IAM users miss the service-to-service paths that attackers prefer because they are quieter and harder to distinguish from normal platform activity. NHI Management Group’s research on NHI breaches shows how over-privileged identities and weak rotation repeatedly appear in real incidents, not as edge cases but as recurring failure modes. See the The State of Non-Human Identity Security findings and the 52 NHI Breaches Analysis for the pattern behind these failures.

In practice, many security teams discover service-role abuse only after data access or cross-account movement has already occurred, rather than through intentional role review.

How It Works in Practice

Start with an inventory of every automatically created, service-linked, or “recommended” role in the AWS estate. Then trace which services assume each role, which buckets, prefixes, and KMS keys they touch, and whether the trust policy allows more principals than the service actually needs. For audit depth, review both managed policies and inline policies, because broad S3 permissions often hide in attachments that were copied once and never revisited.

The fastest way to reduce lateral movement risk is to test whether the role can do more than the service’s documented function. A role used for EMR cluster staging should not be able to read unrelated data lakes, enumerate every bucket, or pass a more privileged role into another workload. The same logic applies to SageMaker and Glue, where backend access is often broader than the operator expects. The MITRE ATT&CK Enterprise Matrix is useful for mapping how credentialed service abuse aligns to known lateral movement techniques, while NIST Cybersecurity Framework 2.0 helps structure the review under asset management, access control, and continuous monitoring.

• Confirm the role trust policy only allows the intended AWS service.
• Check for wildcard actions such as s3:* and iam:PassRole.
• Scope S3 access to named buckets and required prefixes only.
• Remove permissions that are convenient for setup but unused in steady state.
• Log and alert on unusual service-role assumption patterns and cross-service API calls.

Use NHI Lifecycle Management Guide alongside the policy review to make sure default roles are not left in place after a workload changes, because these controls tend to break down when teams assume service-generated permissions remain appropriate after the service scope expands.

Common Variations and Edge Cases

Tighter service-role control often increases operational overhead, requiring organisations to balance least privilege against deployment speed and service compatibility. That tradeoff is real in AWS environments where managed services sometimes need temporary breadth during bootstrap, but current guidance suggests those exceptions should be explicit, time-bound, and reviewed.

One common edge case is a role that looks harmless in isolation but becomes risky when chained with over-privileged identity patterns elsewhere in the account. Another is cross-account analytics or data engineering, where legitimate S3 read access spans many buckets and makes simple allowlists insufficient. In those cases, the audit should focus on blast radius: which buckets are truly required, what actions are necessary, and whether temporary elevation can be replaced with a narrower service boundary.

There is no universal standard for how often every default role must be recertified, but best practice is evolving toward continuous review for high-value services and change-triggered review for lower-risk ones. If the role supports machine learning, data processing, or orchestration, pair the review with the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research because attackers increasingly target reusable cloud identities as a pivot into broader environments.

Related resources from NHI Mgmt Group

• How should security teams detect and contain RBCD abuse in Active Directory before attackers use it for lateral movement?
• How should security teams validate GCP audit-log detections before relying on them in production?
• How should security teams handle exposed cloud keys before attackers use them?
• How should security teams detect lateral movement through service accounts and OAuth grants?