Russia-linked crew keeps winning with app passwords and device codes

The mechanism decides who can fix this, so it is worth being exact about. In both routes Google Threat Intelligence Group describes, the target performs the authorisation. The opening email carries no payload and only asks for a reply to arrange a meeting, with spoofed State Department addresses on the cc line to make the approach look real ^[5]. The attachment that follows is a benign PDF whose entire function is instructions: go to account.google.com and create an app password for a fake State Department cloud environment ^[6]. Nothing is exploited, so nothing built to catch exploitation has anything to catch ^[15].

An app password is a randomly generated 16-character string, and it exists for software that cannot handle 2-step verification ^[4]. The randomness defeats guessing, which was never the threat here; a passcode read out to a helpful diplomat is 16 characters of nothing. Worse, because the feature's whole purpose is to serve clients that cannot do 2SV, the access it grants is not gated by whatever second factor the account holder enrolled in ^[16]. The Microsoft variant asks for the same consent in different clothing, with the target linking a device they do not own to their own Microsoft 365 account ^[8].

Then there is what happened after Google published. The actor registered fresh accounts with usernames close to ones already disabled and went back to the specific people who had answered the first time, keeping the State Department pretence alive ^[9]. Any blocklist of lure names and sender addresses therefore had a useful life measured in weeks ^[17]. The current calendar invitations include a Zoom link, a Google Meet link, and a Microsoft authorisation URL for an application the actor controls ^[10]; the actor's own redirect domain sits in the address bar briefly before the genuine Microsoft 365 sign-in page loads ^[11]. A user asked to spot that is being asked to do security engineering between meetings.

GTIG's attribution is hedged: likely Russia state-sponsored, with only low confidence on the association with APT29 / ICECAP ^[2]. The tradecraft is not hedged, and Citizen Lab documented social engineering against app passwords separately ^[13]. GTIG's own recommendation is instructive about what it thinks is achievable: it says abuse of legitimate authentication features is hard to defend against, and points individuals who may be targeted at Google's Advanced Protection Program ^[12]. That is advice to reduce the surface for named people, not advice to spot the lure.

Which puts two questions where security awareness training cannot reach them. Whether app passwords remain available to accounts in the organisation, and whether device code linking stays on, are not helpdesk calls; they are decisions about which users lose a convenience and which legacy clients break. The campaign ran from at least April into late June against an overlapping set of academics, Russia critics and journalists ^[14], which is long enough to establish that patience is on the other side. The organisations most exposed are the ones where the people carrying the risk are also the ones nobody wants to inconvenience.