How a tampered access-package policy lets a guest self-grant privilege

Entitlement Management lets people request bundled access through access packages, governed by approval and scope policies. The risk is that whoever can edit a catalog can quietly change those guardrails.

How the attack works

An attacker who can delegate or edit a catalog tampers with a privileged package’s assignment policy: they switch it from approval-required to auto-assign and widen the scope to admit external guests. An invited guest then self-requests the package, a bundle of groups, app roles, and a directory role, and is granted all of it with no approval step recorded. The guest signs in and exercises the bundled privilege against an app and directory data. This maps to T1098, Account Manipulation, and T1484, Domain or Tenant Policy Modification.

Why it works

Requesting packages and bundling groups is exactly what the feature is for, so a request blends in. The tell is the policy change that removed approval and widened scope, immediately followed by a privileged grant with no approver in the audit trail. The grant survives because the policy was changed, not because of one user.

How to fix it

Fix the cause and the effect together. Revert the assignment policy to restore approval and original scope, or disable the package, then remove the guest’s assignment to strip the bundled roles, and revoke the guest’s sessions. Disabling one guest leaves the policy primed for the next requester. For the lasting fix, require approval and recurring access reviews on privileged packages, restrict catalog and policy delegation to least privilege, and alert on assignment-policy changes.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse the policy tamper and the containment that fixes the cause, not just one account.