In my last post, we talked about how SageMaker Presigned URLs are effectively "Golden Tickets" to your ML environment. We established that giving users direct IAM permission to generate these tickets (sagemaker:CreatePresigned*) is a recipe for disaster—specifically, lateral movement disaster.
Let’s be real: usually, when we talk about cloud security, we’re talking about S3 buckets left open to the world or over-permissive IAM roles attached to EC2 instances. But while everyone is watching the front door, the Data Science team is building a massive side entrance with Amazon SageMaker.
I’ve been deep-diving into SageMaker security assessments lately, specifically looking at how we access these environments. The verdict? SageMaker Presigned URLs are the "Golden Tickets" of the AWS ecosystem.
If you are a pentester or a Cloud Sec engineer, you need to understand how these URLs work because they are effectively bearer tokens that bypass your IDP, your MFA, and potentially your sanity.
A policy-to-threat-model mapping table showing exactly which IAM policy types mitigate which attack classes, why they matter, and what they do not protect against.
This is the reference table cloud security engineers, auditors, and pentesters use when analyzing IAM blast radius and privilege escalation paths.
For years, one of my go-to TTPs during red team engagements has been bridging the gap between AWS Console access and the CLI. We've all been there: you land on a compromised workstation, or you're stuck in a restrictive VDI environment. You have access to the AWS Console via the browser, but you're handcuffed. You can't run scripts, you can't use tools like Pacu, and you can't mass-enumerate resources efficiently.
I knew the credentials had to be somewhere. AWS doesn't use magic; the browser has to authenticate API calls somehow.