Who Can Rewrite “Allowed”?

Reviewing a system with an attacker’s mindset, I would look for whoever can modify the restrictions imposed on them.

Binance is a cryptocurrency exchange where users buy, sell, and hold digital assets. Its preliminary incident statement described a possible path from a compromised DevOps laptop to unauthorized withdrawals, while reporting no evidence of private-key leakage. The full attack sequence remained unconfirmed.

That raises a question: are we protecting the secret while overlooking the authority surrounding its use?

Consider an account that cannot transfer funds but can update the service requesting transfers. Or one that cannot approve transactions but can change which transactions require approval.

These are hypothetical examples, not confirmed details of the Binance breach.

An attacker looks for paths between capabilities. An operation denied directly may remain possible through something the account can modify.

MITRE’s Valid Accounts technique (T1078) documents how attackers abuse existing credentials. Identifying the compromised account is only the beginning. What could that account influence?

Two approvals may appear independent. Yet if one administrative path can modify both approval mechanisms, their independence needs scrutiny.

My position: the ability to change a security control deserves the same scrutiny as the sensitive operation it protects.

Security reviews should examine both what an account can execute and what it can make possible later.

If an account cannot perform a sensitive operation but can modify the system preventing it, have we actually restricted its authority?