Google: Russia-linked crews get targets to hand over app passwords, OAuth codes and WhatsApp devices

A user who generates an app password and pastes it into a chat window has done nothing a validator can reject. The value is real, the provider issued it, and the login that follows is a correct login. Google's summary reflects that: the signals it offers are sequences rather than artefacts, such as an app password created and then immediately followed by abnormal logins, or access from an unknown address arriving right after an OAuth authorisation ^[10].

Timing is therefore most of the evidence, and the same write-up says post-compromise access arrives over residential proxies or dedicated infrastructure ^[11]. That removes the improbable-geography half of the usual heuristic. What is left to correlate is an authorised consent event against a session that looks ordinary except for being new.

The four domains named do not all attempt the same deception ^[13]. dosportal.app and foreignrelations.us do not impersonate a login brand at all, while wa-connect.eu and drive.google.verify-drive.com do ^[19]. The first pair has no need to, because the pretext is an invitation to a diplomatic event or a notice about a shared document rather than a demand to sign in ^[15]. Someone trained to inspect the address bar before typing a password finds nothing to object to on a page that never asks for one.

The attribution is looser than the framing implies. The work is presented as distinct clusters, and the entity list carries four names: UNC6293, UNC7005, UNC5976 and ICE RELIC, given as APT29 ^[2][18]. The summary does not say which cluster runs which flow, so what transfers into a detection backlog is the technique rather than the actor.

The remediation side is administrative: revoke or block app passwords, enable anti-phishing MFA and advanced protection, audit WhatsApp linked devices on a schedule, and have the target confirm the invitation with the real event organiser on another channel ^[14]. Not one of those is a mail filter, and only the last intervenes while the attack is still running. Where personal accounts are involved, and Google notes the activity may leave no trace in corporate systems at all ^[12], every one of those controls has to be exercised by the account holder rather than by an administrator. That is the part worth arguing about internally: the identity events that matter here are generated by the user, on infrastructure the employer does not read, and the recovery step is a person deciding to check their own linked devices.