Our paper on catching an attacker who already has a valid key, and what building it showed us

"Risk-Adaptive Authorization for Hybrid Cloud IAM" is eighth-semester work at Madan Bhandari Memorial College, Tribhuvan University, written with Ashal Pandey and Famous Dhungana. It is not published. No journal has taken it, nobody outside the team has reviewed it, and the tests it describes have not been run. So read what follows as a design and an argument, not as a result.

It is on this site anyway, in full, because a design nobody has measured is still a design you can read and argue with. What it should not get is the credit for an experiment it has not done, and the demo page says so at the top rather than in a note at the bottom.

The attacker this paper cares about already has a working key. They phished it, found it in a repository, or lifted it off a build machine. From then on they use it the way its owner would, taking a little more power with each ordinary command. Every request is properly signed. Every command is one that normal deploy tools run every day. Nothing looks wrong, because at the level the request is checked, nothing is wrong.

The two obvious defences each fail, and they fail on opposite cases. Watch behaviour only, and a patient attacker walks past you. Give them a few weeks and they look normal, so the request that finally hands over admin rights looks no stranger than the hundred harmless ones before it. Check permissions only, and you block the wrong person, because the engineer fixing an outage at two in the morning types the very same command. A system that only asks what a request would unlock cannot tell those two people apart.

A broker sits in front of the cloud and asks two things. Is this account behaving the way it usually does, judged against its own history rather than against everyone else's? And how much power would this single action hand it? The second is worked out from a map of permissions, comparing what the account can reach now with what it could reach if the request went through, and weighting each permission by how much damage it can do. A lighter third check looks at the situation, such as a strange location, an odd hour, or a jump from the office network into the cloud.

The three are added into one score with weights of 0.4, 0.4 and 0.2, which the paper is honest about having picked rather than worked out. The score lands in one of four levels at 0.35, 0.55 and 0.75, and that level is read against how sensitive the target is. The table only ever gets stricter, so a higher level or a more sensitive target never gives back an easier answer. The result is allow, question, or refuse.

The middle answer is the point of the whole thing. The engineer with a real reason gets asked to confirm and carries on. The attacker, who has the key but not the second factor, is stopped by the same rule that let the engineer through.

The demo is a page that runs entirely in your browser. Nothing on it is a recording. It models a hundred permissions worth 412 points of damage between them, of which the deploy account can already reach twelve, and it trains its model on generated everyday traffic when the page opens. Seven situations run through it, six attacks from the paper and one honest case, the real administrator doing the same privileged work.

Every number is adjustable on the page, and one switch opens the full working behind any answer along with the permission map it came from. Two scripts check the same figures without a browser. One works through the examples in the paper and compares them with the build, calculating each figure instead of comparing against a saved one. The other prints every situation request by request, with each part of the score, the total, and the rule that decided it.

The paper contradicts itself. One section says a machine account cannot answer a security prompt, so being questioned becomes being refused. Another applies that rule only to brand new accounts. Then the worked example later on shows a deploy robot being questioned, and a deploy robot is a machine account. Both readings are fair and the paper never settles it, so the demo turns the choice into a labelled switch instead of quietly deciding in code. Switch it off and the paper's example comes out exactly right.

The training data had to include honest privileged work. Two of the behaviour checks are simple yes or no flags: did anything in this window change permissions, and did a look around lead straight into one. If the everyday traffic is nothing but routine reads, those flags almost never fire while the model is learning, so afterwards it treats anything carrying either as suspicious, including the engineer doing a genuine emergency fix. That is exactly the mistake the honest test case exists to catch, and our design was making it. Once accounts that really do privileged work started doing it in the training data too, the engineer got questioned instead of blocked.

A rounding difference in the worked examples. Two weights are usually written as 0.67 and 0.33, which puts one figure at 0.779 and 0.670. Exact thirds put it at 0.777 and 0.667. No answer changes, and the page notes the difference under the table rather than quietly picking one.

There is no test setup behind the page. No containers, no proxy, no stand-in cloud, and therefore no timing figure of any kind. The speed tables in the paper are a plan with the results column still empty, and they are shown that way rather than filled in.

The example traffic was written by the same design it is testing. That is a real weakness, the paper says so in its own limits section, and a demo cannot get around it. The page shows what the design does when its own assumptions hold. Whether they hold against traffic nobody on the team wrote is the experiment, and the experiment is still to do.