Some accounts are not named "admin" but can turn themselves into admin. I plant six of them on purpose across AWS and Azure, run CyberArk's SkyArk to hunt them, and score what it catches against what I buried.
| Domains | CyberArk/Idira, AWS, Azure |
| Built on | cyberark/SkyArk (AWStealth + AzureStealth) |
| Cost | Under $2. Runtime ~5 hours |
| Status | Escalation path EXERCISED on real AWS: a shadow user with only iam:AttachUserPolicy self-granted admin in one call (findings/real-aws-escalation-proven.txt). Ground truth 4/4. AWStealth + Azure half still pending |
A shadow admin is an account that can quietly become admin. It might pass a role onto an admin, rewrite its own policy, or grant itself Owner in Azure. None of them are named admin. All of them are game over. Most people run SkyArk once against production, get a scary list, and never learn why each finding is dangerous.
Turn that scan into a graded test. If I know exactly what is planted, I can measure what the tool actually catches.
I built two cloud tenants with six escalation paths planted, each using one known trick and each looking harmless in a permission review:
| Principal | Trick | Looks like | Actually |
|---|---|---|---|
| passrole | PassRole + RunInstances | some EC2 access | launches an instance wearing the admin role |
| policyversion | CreatePolicyVersion | can list S3 buckets | rewrites its own policy to allow everything |
| attach | AttachUserPolicy | policy management | attaches full admin to itself |
| assumer | broad trust policy | a low access user | assumes admin through a loose trust |
| ops (Azure) | roleAssignments write | vm operations | grants itself Owner |
| graph app (Azure) | Directory.ReadWrite.All | a service principal | resets any user's credentials |
Then I wrote a scorer that diffs SkyArk's output against a ground truth file into three buckets: caught, missed, and extra.
Exercised on real AWS: a planted shadow admin escalated itself to full administrator in a single call. Using only its own credentials — one permission, iam:AttachUserPolicy, nothing named "admin" — the user attached AdministratorAccess to itself and it took effect. That is the entire thesis of the lab, demonstrated rather than described: the danger is not the users that look powerful, it is the one innocuous permission that is a straight line to admin, and an access review grepping for AdministratorAccess never sees it. Cost $0, IAM only, torn down after. Full output in findings/real-aws-escalation-proven.txt.
Underneath that, the engineering that makes the audit trustworthy: a scoring harness that verifies the ground truth — the baseline SkyArk gets graded against — matches deployed IAM in both directions, so a path described-but-not-deployed or deployed-but-undescribed cannot silently corrupt the score. 9 offline tests, plus negative controls I induced by hand to prove the checker actually fails when the baseline is wrong.
The whole thing runs on a deliberately-planted taxonomy of six escalation paths mapped to the Rhino Security Labs primitives — the missed one is the point, the gap between what a scanner claims and what it does. Notes in LAB-NOTES.md.
This lab creates real escalation paths. The guardrails refuse to run in an Organizations management account or any account not on an explicit allowlist, and everything is tagged as intentionally insecure. Throwaway account only. make destroy when done.
SkyArk is CyberArk's. The planted environment, the ground truth, the scorer, and the tests are mine.
make deploy-aws
make deploy-azure
make scan
make score
make destroyNeeds Terraform 1.9+, PowerShell 7+, Python 3, AWS and Azure test tenants.
findings/scorecard.md comes from make score. LAB-NOTES.md is the log.
Lab code: MIT (LICENSE). SkyArk stays MIT, credited above.