Service-linked roles (SLRs) are IAM roles AWS creates and manages on behalf of its own services — AWSServiceRoleForECS, AWSServiceRoleForAutoScaling, AWSServiceRoleForConfig, and 180+ others as of April 2025. They are designed to reduce customer IAM toil, and they do. They also concentrate privilege in a narrow set of trust relationships that most detection tooling treats as implicitly benign. Throughout 2024, researchers from Datadog, Wiz, and Palo Alto Unit 42 published a steady drumbeat of abuse primitives — Aaron Kaplan's August 2024 Black Hat talk "The SLRs Are Coming From Inside The House" remains the clearest survey. In Q1 2025, CloudTrail data from incidents I participated in showed SLR-mediated lateral movement in 3 of 7 cloud breach investigations. This post catalogs the abuse patterns worth detecting now.
Why are service-linked roles disproportionately abused?
They carry AWS-managed policies that cannot be tightened, and they are trusted by default. An attacker who gains the ability to invoke a service that uses an SLR inherits that SLR's effective permissions transitively. The AWSServiceRoleForTrustedAdvisor role, for example, has read access to every service in every region, and an attacker with support:* and iam:PassRole can trigger operations that execute under it. Unlike customer-managed roles, you cannot simply scope the SLR down — you either accept the policy or disable the service.
What is the EventBridge invocation pivot?
An attacker with events:PutRule and events:PutTargets on a specific event bus can create rules that invoke downstream services under their SLRs. The canonical example: a user with no direct lambda:InvokeFunction permission writes a scheduled rule that targets a Lambda function. EventBridge invokes Lambda under AWSServiceRoleForCloudWatchEvents, which has lambda:InvokeFunction on any function in the account. CloudTrail records the invocation as eventSource: lambda.amazonaws.com, userIdentity.type: AWSService, which most alerting rules exclude as noise.
aws events put-rule --name covert-exec --schedule-expression "rate(5 minutes)"
aws events put-targets --rule covert-exec \
--targets "Id=1,Arn=arn:aws:lambda:us-east-1:111111111111:function:prod-job"
Detection: alert on PutRule + PutTargets where the target is in a different account or invokes a function the rule creator cannot directly invoke.
How does SSM ConfigRecording abuse work?
AWS Config uses AWSServiceRoleForConfig to record resource configurations, including Systems Manager documents. An attacker with config:PutConfigurationRecorder can enable recording of SSM documents in an account where recording is disabled, causing AWS Config to read document content — including those holding SecureString parameters referenced by the document. The technique was published by Nick Frichette of Hacking the Cloud in February 2025 and works because the Config SLR's read permissions on SSM were expanded in January 2024 without a corresponding customer-visible announcement.
What is the "PassRole to service" technique?
Any attacker who holds iam:PassRole for an SLR-adjacent role can often chain it into privilege escalation by passing the role to a service the victim did not expect. The classic example from Wiz's March 2025 research: passing a role with s3:* on a specific bucket to codebuild:StartBuild with an attacker-controlled buildspec, where CodeBuild then uses its own SLR plus the passed role. Because CodeBuild's SLR (AWSServiceRoleForCodeBuild) is trusted by CloudWatch Logs, the attacker can tee build output — including secrets — to a log group they read.
Detection: CloudTrail PassRole events where the passed role has wide data-plane permissions and the receiving service is CodeBuild, Glue, SageMaker, DataBrew, or Step Functions.
Can we harden SLRs without breaking services?
Partially. SCPs are the only enforceable control — you cannot modify the attached policy, but you can deny the service from assuming roles outside expected regions, or block PassRole to SLR-adjacent services unless the passed role carries a required tag:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": { "iam:PassedToService": "codebuild.amazonaws.com" },
"StringNotEquals": { "aws:ResourceTag/CodeBuildAllowed": "true" }
}
}]
}
Combined with AWS IAM Access Analyzer's unused-access findings (GA March 2024), this catches the long tail of lingering iam:PassRole permissions that enable the attack chain in the first place.
What about detection via CloudTrail?
CloudTrail records SLR-mediated actions with userIdentity.sessionContext.sessionIssuer.type: "Role" and the role ARN in the SLR namespace. Most SIEM rules strip these as "AWS internal." Invert the rule: alert on any SLR invocation that crosses a service boundary in a way the customer-side IAM policy should not permit. A useful Athena query against CloudTrail logs:
SELECT eventtime, eventname, useridentity.arn, resources
FROM cloudtrail_logs
WHERE useridentity.sessioncontext.sessionissuer.arn
LIKE '%AWSServiceRoleFor%'
AND eventname IN ('PutObject','GetObject','Invoke','StartExecution')
AND date_parse(eventtime,'%Y-%m-%dT%H:%i:%sZ') > current_timestamp - interval '1' day;
Tune by excluding known legitimate SLR traffic (AutoScaling lifecycle, Config snapshots) and investigate the remainder.
How Safeguard Helps
Safeguard ingests CloudTrail, AWS Config, and IAM Access Analyzer findings and maps them against an asset graph that tracks SLR-mediated trust relationships as first-class edges. Griffin AI performs reachability analysis on IAM policies to identify which iam:PassRole grants actually enable privilege escalation through SLR chains — dramatically reducing the noise from benign PassRole permissions. TPRM workflows cover upstream AWS-integrated vendors (Datadog, Snyk, Wiz) whose cross-account roles leverage SLR patterns, scoring them against least-privilege benchmarks. Policy gates block Terraform or CloudFormation changes that introduce wildcard PassRole permissions to SLR-adjacent services, and Safeguard's audit log feeds directly into your detection pipeline for correlation with CloudTrail telemetry.