The IAM privilege escalation hidden behind a stale date

A condition is more than present or absent

A check that reads an IAM Condition block as present-or-absent has to pick one answer for every dangerous grant that carries a condition: either the condition constrains it, or it doesn't. Whichever it picks, it is wrong for one of the two policies below.

The standard test for exactly this is Bishop Fox's iam-vulnerable, a reference corpus of real AWS IAM privilege-escalation paths. Buried in it is a matched pair named for the two ways a check can get it wrong: fn3 (a false negative waiting to happen) and fp5 (a false positive). They're almost identical.

One operator apart

Both policies grant iam:CreatePolicyVersion on Resource: "*" — a classic escalation (rewrite a policy you're attached to, grant yourself admin). Both add one condition on aws:TokenIssueTime, the moment a temporary credential was issued. They differ by a single operator:

fn3  →  "DateGreaterThan": { "aws:TokenIssueTime": "2020-01-01T00:00:01Z" }
fp5  →  "DateLessThan":    { "aws:TokenIssueTime": "2020-01-01T00:00:01Z" }

What audytx does with the pair

To resolve the pair, a check has to read the condition itself — the operator, the key, the value — and ask whether it still constrains anything. audytx does, and gets both policies right.

Checked against the live engine on July 1, 2026. Both outcomes are pinned by tests in the audytx engine.

What this proves

This is one policy in one benchmark, chosen because it separates a check that reads a condition from one that only counts it. A security tool should understand what a control does before it trusts it — and stay quiet when the control is real.

audytx reads condition operators, not just whether a condition is present. It gets both halves of the fn3/fp5 pair right: the live escalation is flagged and the dead one is not.