Catching an attacker who has a real password
Most cloud break-ins involve no breaking. Someone gets hold of a working key, then uses it to hand themselves more power, one ordinary command at a time.
Every request is properly signed. Every command is one that real deployment tooling runs daily. Nothing looks wrong, because technically nothing is wrong.
The system shown here asks two questions before it lets anything through. Is this account behaving the way it normally does, and how much power would this single action hand over?
Ask only the first and a patient attacker walks straight past you. Ask only the second and you lock out the engineer fixing an outage. Ask both and you can tell them apart.
Aalok Bhandari
Ashal Pandey
Famous Dhungana
BSc CSIT, eighth semester
Madan Bhandari Memorial College
Tribhuvan University
training…
Worth saying up front. None of these figures are measurements. The system is built and it runs, but it has not been tested against real traffic yet, and the example accounts and attacks were written by the same people who designed it. This page shows what the design does. It is not evidence that the design works.
Watch it happen
Pick a situation and press play. Each column is one thing somebody tried, and how high the bar rises is how much the system minded.
A stolen key goes looking for a way up
A deployment robot's access key, in someone else's hands
The key works, so the cloud answers every request without complaint. Whoever has it starts small: who am I, what am I allowed to do, what roles exist here. Then it asks to be made an administrator.
None of these commands are exotic. Real deployment tools run every one of them daily. What stands out is the sequence, and then how much the final request would unlock.
Setting up the example…
Why it needs both halves
Each half fails on its own, and they fail on opposite cases. That is the entire argument for putting them together.
A patient attacker
Someone who took their time. They poked around quietly for long enough that the system started treating their activity as ordinary. Then they asked to be made an administrator.
Wrong answer. It misses them. Their behaviour stopped looking unusual weeks ago, and nothing in this approach registers that the last request is a different kind of thing from the ones before it.
Right answer. Caught. The behaviour barely registers, but the request would hand over the entire account, and that alone is enough.
A real administrator
An engineer doing the identical thing for a real reason. Middle of the working day, from the office, as part of a sequence they have run dozens of times.
Wrong answer. Blocked. This approach cannot tell the engineer from the attacker, because the two requests are the same request. The outage carries on while the one person who could fix it waits outside.
Right answer. Asked to confirm, then let through. Nothing about how they are working is out of character, so the request gets checked instead of refused.
What it cannot do
All of this is in the paper. A security design that only advertises what it catches is not worth reading.
Each of these is wired into the real decision. Switch one on and the verdicts above change with it.
Setting up…
Anything happening inside a server, below the cloud's own commands
It only ever sees requests made to the cloud. Whatever runs inside a machine afterwards is invisible to it.
Reading or stealing data without changing any permission
If the account already has access, copying the data unlocks nothing new. Only the behaviour side has anything to say, and it may not say much.
An attacker patient enough to be absorbed into the baseline
Behave normally for long enough and normal is what you become. Patience does nothing to the power check, and that is the only reason this counts as partly covered.
Anyone who compromises the checkpoint itself
The whole thing assumes the attacker is outside the checkpoint. If they are not, none of it applies.
The working
None of this is needed to follow the story above. It is here because a demonstration you cannot interrogate is a poster.
What happens when you remove one halfthe baselines and ablations, worked out+–
These two ablations are what make the claim falsifiable. If the full system fails to beat both of them, then combining the two signals bought nothing over whichever one was already better, and the central argument collapses. Running them costs nothing beyond setting one weight to zero, so there was never an excuse to leave them out.
| Case | Configuration | Computation | R | Verdict | |
|---|---|---|---|---|---|
| Patient adversaryA = 0.30, G = 1.00, C = 0.33 | Proposed | 0.40(0.30) + 0.40(1.00) + 0.20(0.33) | 0.586 | BLOCKED | Behavior is unremarkable because the activity was paced into the baseline. The structural term is what carries it. |
| B3 — behavior only | 0.67(0.30) + 0.00(1.00) + 0.33(0.33) | 0.310 | ALLOWED | Misses it. Without G(r) nothing marks this operation as more consequential than any other. | |
| B4 — structure only | 0.00(0.30) + 0.67(1.00) + 0.33(0.33) | 0.777 | BLOCKED | Catches it, and would catch the administrator below in exactly the same way. | |
| Legitimate administratorA = 0.05, G = 1.00, C = 0.00 | Proposed | 0.40(0.05) + 0.40(1.00) + 0.20(0.00) | 0.420 | ASKED TO PROVE IT | Challenged rather than refused. The administrator answers it and the work proceeds. |
| B4 — structure only | 0.00(0.05) + 0.67(1.00) + 0.33(0.00) | 0.667 | BLOCKED | Blocks the administrator. Structurally this request is identical to the attack above. |
IAM policy applied once, with no re-evaluation
Fixes the floor. Any call within the principal's configured entitlement succeeds, which is why an over-permissive grant is a standing escalation path.
Known escalation patterns matched in the telemetry stream
Matches after the operation has completed. The alert is real; the attachment has already taken effect, and the outcome depends on how quickly an analyst responds.
wG = 0, remaining weights renormalised
Removes the permission-flow term. Nothing marks one operation as more consequential than another, so a patient adversary whose activity has been partly absorbed into the baseline passes.
wA = 0, remaining weights renormalised
Removes the behavioral term, leaving an approximation of configuration-time reachability analysis operating at request time. It catches the escalation and cannot tell an attacker from an administrator performing the same operation.
Every constant, adjustableweights, thresholds, consequence, window length+–
These are the paper's prototype settings. It says outright that they were chosen, not tuned, and not derived from any data. The evaluation plan includes a sweep across them for exactly that reason: a result that only holds at one setting is an accident, not a finding. This panel is that sweep, by hand.
refitting…
Every control is at the paper's prototype value.
prototype: wA=0.4, wG=0.4, wC=0.2, α=0.35, β=0.55, γ=0.75, κ=(25, 5, 1), W=15 min
The full attack coverage tableincluding everything it misses+–
Four of the seven rows read not detected. They are in Table X of the paper and they are here for the same reason: a coverage table that lists only what a design catches is not a coverage table. Two of the four are outside control-plane telemetry altogether, one violates the assumption every property rests on, and one places the adversary outside the stated threat model.
| Attack behavior | Coverage | Basis and residual risk |
|---|---|---|
| Permission enumeration | DETECTED | Novel action families and volume relative to baseline; behavioral term only, as G(r) = 0 |
| Delegation escalation | DETECTED | Operation extends closure to administrative authority; G(r) approaches unity for the requested operation |
| Gradual evasion by paced activity | PARTIAL | Baseline adapts to the adversary; the permission-flow term is unaffected by pacing |
| In-instance activity below the API layer | NOT DETECTED | Outside control-plane telemetry |
| Data-plane access without permission change | NOT DETECTED | G(r) = 0; only the behavioral term can contribute |
| Broker bypass or direct control-plane access | NOT DETECTED | Violates the assumption on which every property rests |
| Compromise of broker, analytics or PDP | NOT DETECTED | Adversary is outside the stated threat model |
| ID | Category | Primitive | Description |
|---|---|---|---|
| S1 | Permission delegation | AttachUserPolicy | Compromised principal attaches an administrative managed policy to itself |
| S2 | Permission delegation | PutUserPolicy | Inline policy written granting identity-mutating actions |
| S3 | Credential takeover | CreateAccessKey | Additional access key created for a higher-privileged principal |
| S4 | Credential takeover | UpdateLoginProfile | Console credential set on a principal held by another party |
| S5 | Multi-step chain | Enumeration then S1 | Permission discovery followed by delegation within one session |
| S6 | Cross-plane chain | On-premises logon then AssumeRole then S1 | Directory credential used on-premises, federated into the cloud plane, then delegation attempted |
| B0 | Benign control | Mixed operations | Legitimate administrator performing S1-equivalent operations in routine work |
The evaluation that has not been run yetthe measurement plan, and the empty tables waiting for it+–
Tables VIII and IX are instruments, not results. The metric definitions and measurement procedures are fixed; the values they will take are obtained only by running the program of Section 5, and that program has not been run. Every value cell below reads NOT YET RUN because that is what it currently contains.
| Metric | Definition | How obtained | Status |
|---|---|---|---|
| Precision | TP / (TP + FP) over requests receiving step-up or deny | Verdict log scored against injection labels | NOT YET RUN |
| Recall | TP / (TP + FN) over adversarial requests | Verdict log scored against injection labels | NOT YET RUN |
| F1 score | Harmonic mean of precision and recall | Derived from the two above | NOT YET RUN |
| False positive rate | FP / total benign requests | Verdict log over the benign partition | NOT YET RUN |
| PR-AUC | Area under the precision–recall curve | Curve traced by sweeping | NOT YET RUN |
| Per-category recall | Recall computed separately for S1–S2, S3–S4, S5, S6 | Labels carry scenario identity | NOT YET RUN |
| B0 false positives | Benign-administrator requests denied or challenged | Scenario B0 verdicts | NOT YET RUN |
| Adversarial share | Injected requests as a proportion of total volume | Recorded at generation time | NOT YET RUN |
| Session window W | Duration of the behavioral window | Fixed configuration value | NOT YET RUN |
| Metric | Definition | Condition | Status |
|---|---|---|---|
| Authorization latency | Wall-clock time added to the request path, at p50, p95 and p99 | Full system vs broker-only | NOT YET RUN |
| Graph closure time | Time to compute both reachability closures for one request, p95 | Full system only | NOT YET RUN |
| Graph rebuild time | Time to rebuild the graph after a permitted mutating operation, p95 | Full system only | NOT YET RUN |
| Behavioral staleness | Age of the anomaly score at the moment of decision, p95 | Full system only | NOT YET RUN |
| Policy evaluation time | Time spent inside the policy engine, p95 | Full system vs broker-only | NOT YET RUN |
| Mean CPU utilization | Average across all containers during a run | Full system vs broker-only | NOT YET RUN |
| Peak memory | Maximum resident set across all containers | Full system vs broker-only | NOT YET RUN |
| Sustained throughput | Requests per second at which latency p95 remains stable | Full system vs broker-only | NOT YET RUN |
| Element | Specification |
|---|---|
| Cloud plane | Local AWS emulator with IAM policy enforcement enabled [19] |
| Identity provider | Open-source IdP federating both planes [20] |
| Policy engine | Open Policy Agent, decision logs enabled [18] |
| Inline broker | Python reverse proxy on the control-plane request path |
| On-premises plane | Containerised service behind reverse-proxy enforcement point |
| Analytics | Python; scikit-learn isolation forest and one-class SVM |
| Host | Commodity workstation; exact specification recorded at experiment time |
| Composition | Docker Compose with pinned image digests, released as artifact |
How the research was carried outsix stages, eight revisions after review, references+–
Stage 1 — Scope validation
The initial topic covered Zero Trust, continuous authentication, hybrid cloud and AI behavioral analytics simultaneously, which is more than a semester project can defend. It narrowed to one attack class, control-plane privilege escalation, and one enforcement mechanism, with the available resources fixed in advance: a commodity workstation, no cloud budget, roughly one month.
Stage 2 — Literature survey and gap derivation
Four strands were surveyed: the Zero Trust standards, the cloud IAM escalation literature, behavioral and insider-threat analytics, and the tooling layer. Every reference was checked against its publishing venue before entering the paper. The comparison was built as Table I first and the gap was read off the table, rather than asserted and then justified.
Stage 3 — Dataset investigation and the decision to generate
Both candidate public corpora were rejected for metric computation: the CERT insider-threat corpus has exact labels but records on-premises endpoint activity, and the flaws.cloud CloudTrail corpus is genuine cloud telemetry with no per-event labels and almost no benign baseline. Generating the corpus inside the testbed makes the training and target domains coincide and makes labels exact by construction. Both public datasets are still cited, for validating the action taxonomy rather than for producing numbers.
Stage 4 — Architecture and mechanism design
The architecture was specified component by component: inputs, outputs, synchrony, and behavior under failure. The risk function was written down completely — every variable, its domain, its normalization, and its degenerate cases — specifically so that it could be attacked. A risk formulation with unstated weights cannot be criticised, and cannot be defended either.
Stage 5 — Evaluation design
Baselines were chosen to make the claim falsifiable rather than to make it look good. The two ablations, B3 and B4, cost nothing to run and are the configurations most likely to defeat the proposal. Scenario B0 exists for the same reason. Metrics, the unit of classification and the statistical treatment were fixed before any run, so that criteria cannot drift once results appear.
Stage 6 — Hostile review and revision
The draft was reviewed against a checklist of the failures that sink student papers: unsupported claims, overstated novelty, unstated assumptions, mathematical gaps, circular reasoning, and results implied but not obtained. The eight changes it produced are listed below rather than summarised, because these are what an examiner may probe.
- 01The decision unit was ambiguous. Risk was written R(s) over a session window, but the permission-flow term is a property of one requested operation. Rewritten as R(r) with s(r) denoting the trailing window, which is what allows the model to express a principal behaving normally while requesting one operation of large consequence.
- 02Synchrony was unspecified. Blocking every request until a window score is computed is not implementable. The behavioral engine is now explicitly asynchronous with a bounded staleness, and the staleness is reported as a measured quantity rather than left implicit.
- 03Failure behavior was missing entirely. Section 3.8 now specifies what happens when the behavioral store, the permission-flow service or the decision point is unavailable, and marks degraded decisions in the audit record.
- 04The gap claim was too strong. “No published work combines…” is not something a survey of ten papers can establish. Reworded to a claim about the literature surveyed, with an explicit statement that it is not offered as proof of universal absence.
- 05The decision matrix contained an apparent redundancy: γ has no effect on low-sensitivity resources. It is now stated as a deliberate policy choice with its reasoning, together with the monotonicity property of the matrix.
- 06Training and test separation was vague, leaving open whether attack traffic could enter model training. Section 5.2 now specifies temporal partitioning with a benign-only training partition, and notes that this excludes baseline poisoning from the experiment but not from the deployed system.
- 07The unit of classification was undefined, which would have made precision and recall uninterpretable. It is now the individual request, defined explicitly.
- 08The self-generated corpus creates a circularity: the same authors design both the detector and the data it is tested on. Section 5.7 states this as a threat to validity, with two partial mitigations and an acknowledgement that neither substitutes for real telemetry.
- [1]S. Rose, O. Borchert, S. Mitchell, and S. Connelly, "Zero Trust Architecture," NIST Special Publication 800-207, Aug. 2020. https://doi.org/10.6028/NIST.SP.800-207
- [2]R. Chandramouli and Z. Butcher, "A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments," NIST SP 800-207A, Sep. 2023. https://doi.org/10.6028/NIST.SP.800-207A
- [3]N. F. Syed, S. W. Shah, A. Shaghaghi, A. Anwar, Z. Baig, and R. Doss, "Zero Trust Architecture (ZTA): A Comprehensive Survey," IEEE Access, vol. 10, pp. 57143–57179, 2022. https://doi.org/10.1109/ACCESS.2022.3174679
- [4]L. Ferretti, F. Magnanini, M. Andreolini, and M. Colajanni, "Survivable zero trust for cloud computing environments," Computers & Security, vol. 110, art. 102419, Nov. 2021. https://doi.org/10.1016/j.cose.2021.102419
- [5]MITRE Corporation, "ATT&CK Matrix for Enterprise: Cloud." https://attack.mitre.org/matrices/enterprise/cloud/
- [6]Y. Hu, W. Wang, S. Khurshid, and M. Tiwari, "TAC: Hybrid IAM Privilege Escalation Detection," arXiv:2304.14540, version 8, Mar. 2026. https://arxiv.org/abs/2304.14540
- [7]I. Shevrin and O. Margalit, "Detecting Multi-Step IAM Attacks in AWS Environments via Model Checking," in Proc. 32nd USENIX Security Symposium, 2023, pp. 6025–6042.
- [8]S. Gietzen, "AWS IAM Privilege Escalation — Methods and Mitigation," Rhino Security Labs, 2018. https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
- [9]Rhino Security Labs, "Pacu: The Open Source AWS Exploitation Framework." https://github.com/RhinoSecurityLabs/pacu
- [10]E. Steringer, "Principal Mapper (PMapper)," NCC Group. https://github.com/nccgroup/PMapper
- [11]Splunk Threat Research Team, "AWS IAM Privilege Escalation," Splunk Security Content, 2021. https://research.splunk.com/stories/aws_iam_privilege_escalation/
- [12]S. Piper, "Public dataset of CloudTrail logs from flaws.cloud," Summit Route, Oct. 2020. https://summitroute.com/blog/2020/10/09/public_dataset_of_cloudtrail_logs_from_flaws_cloud/
- [13]J. Glasser and B. Lindauer, "Bridging the Gap: A Pragmatic Approach to Generating Insider Threat Data," in Proc. 2013 IEEE Security and Privacy Workshops, pp. 98–104. https://doi.org/10.1109/SPW.2013.37
- [14]D. C. Le, N. Zincir-Heywood, and M. I. Heywood, "Analyzing Data Granularity Levels for Insider Threat Detection Using Machine Learning," IEEE TNSM, vol. 17, no. 1, pp. 30–44, Mar. 2020.
- [15]F. T. Liu, K. M. Ting, and Z.-H. Zhou, "Isolation Forest," in Proc. 8th IEEE International Conference on Data Mining (ICDM), 2008, pp. 413–422.
- [16]B. Schölkopf, J. C. Platt, J. Shawe-Taylor, A. J. Smola, and R. C. Williamson, "Estimating the Support of a High-Dimensional Distribution," Neural Computation, vol. 13, no. 7, pp. 1443–1471, 2001.
- [17]P. A. Grassi, J. L. Fenton, E. M. Newton, et al., "Digital Identity Guidelines: Authentication and Lifecycle Management," NIST SP 800-63B, 2017. https://doi.org/10.6028/NIST.SP.800-63b
- [18]Open Policy Agent Project, "Open Policy Agent Documentation," CNCF. https://openpolicyagent.org/docs/
- [19]LocalStack, "LocalStack Documentation." https://docs.localstack.cloud/
- [20]Keycloak Project, "Keycloak Documentation," Red Hat. https://www.keycloak.org/documentation
- [21]Amazon Web Services, "Policy Evaluation Logic," AWS IAM User Guide. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html