An adversary-in-the-middle proxy does not need the second factor to be weak. It needs it used once, in front of a page that relays it, after which the thing worth stealing is the cookie the identity provider returns [8]. ANY.RUN puts the gap in authentication and session management rather than in the factor itself [9], and that distinction is the whole story: the password reset that closes most ticket queues does nothing to a cookie already in someone else's browser [11].
The arithmetic in the writeup is worth doing. More than 9,000 potential compromise events [5] spread across 4,532 organization email domains [4] works out to about two events per domain [15]. That ratio is coarse, because the event categories overlap by design: cookie theft, password theft, SSO logins and 2FA bypass are counted in the same bucket [5], and a single hijacked account can plausibly generate several. Still, it does not look like a spray that landed once per target. Neither does the reported hit rate of 48% of targeted addresses, which is a shade under one in two [2][16].
The hedging deserves attention too. "Potentially compromised" and "potential compromise events" are the load-bearing words [2][5], and the denominator behind them is not published. This is one vendor's telemetry: the two source texts supplied here are the same Hacker News article [14], and it arrives alongside ANY.RUN's own product numbers, including detection in 14 seconds, 21 minutes off mean time to respond per case, and feed data drawn from more than 16,000 organizations [13]. Take the campaign shape seriously and the counts as a floor of unknown height.
What the piece does not say is which authentication methods the victims had switched on [19]. Without that, nobody can claim from this data that phishing-resistant credentials would have stopped it, only that conventional MFA did not [9]. The recommendations stop at prioritising phishing-resistant authentication, behavioural detection and response built for session theft [20], plus revoking sessions and tokens and investigating the identity rather than resetting the password [10]. Those are the right instincts and they stop one step short of the mechanism. If the stolen artifact is a bearer token, the fix is to stop it being a bearer token: bind it to the device that obtained it, and put conditional access in the path so a replay from unfamiliar infrastructure fails the check rather than merely logging it. Neither control is named in the writeup, which is a gap in the advice, not in the finding.
For operators, the practical delta is in the runbook. Technology, manufacturing and education came up most often as targets [7], and any of them can answer a questionnaire truthfully with "MFA enforced" while having no tested procedure for pulling refresh tokens on a Friday night.
