Most of us think of an account takeover as someone guessing or stealing a password. But a pattern showing up across several recent incidents works differently: the attacker never touches your password at all. Instead, they get you to hand over something that acts like a spare key to an account you're already logged into — a linked device, an authorization token, a session — and walk right past the locks you'd normally rely on.

Two examples make the mechanism concrete. Security researchers recently described a WhatsApp scam spreading from already-hijacked accounts, where a message asks you to "vote" for a friend in a contest. It routes you through a page that mimics WhatsApp's "linked device" setup, or tells you to type a code into your own linked-devices menu. Completing that flow adds the attacker's phone as a second, fully-authorized device on your account — full read and send access — without them ever entering a password. Because no password was touched, you get no password-reset email and no failed-login alert. The rogue session just sits quietly in your device list as one more entry.

Separately, Microsoft has warned about a campaign abusing hotel and conference Wi-Fi captive portals — the "agree to terms" page you see when you connect. Attackers in the network path redirect victims to fake login pages or fake "device code" prompts that, once completed, hand over authorization tokens rather than passwords. The effect is the same: a session that looks legitimate to the service, because technically it is one — it just belongs to someone else now.

Why your usual defenses miss this

A password manager protects the password. Two-factor authentication protects the moment you log in. Neither one is watching what happens after a session or device gets authorized, which is exactly the gap these attacks are built for. The only reliable way to catch this category of compromise is to periodically check, by hand, which devices and apps currently have standing access to your accounts — not to wait for an alert that these attacks are specifically designed not to trigger.

The 15-minute session audit

Do this for the accounts that matter most (email, WhatsApp/Telegram, banking, and anything tied to your identity or money), and set a recurring reminder to repeat it. Where menu names change over time, look for wording like "devices," "sessions," or "connected apps":

  • WhatsApp: Settings → Linked Devices. Anything you don't recognize, tap it and log it out immediately.
  • Google: myaccount.google.com/security → "Your devices" and, separately, "Third-party apps & services" (sometimes labeled "Sign in with Google"). Revoke access for anything you don't actively use.
  • Microsoft account: account.microsoft.com/devices for device list; account.microsoft.com/activity for sign-in history.
  • Apple ID: Settings → [your name] on an iPhone/iPad, or System Settings on a Mac, shows every device signed into your Apple ID.
  • Facebook/Instagram (Meta): Settings → Accounts Center → Password and security → Where you're logged in.
  • Banking and financial apps: most have a "manage devices" or "active sessions" screen under security settings, though the wording varies by institution — check yours now so you know where it is before you need it.

While you're in these menus, also glance at any "connected apps" or OAuth grants list — old apps and browser extensions you authorized years ago and forgot about are exactly the kind of standing access this class of attack tries to create fresh.

If you find something you don't recognize

Remove or log out the unfamiliar device or app first — don't wait. Then, even though the attacker may not have needed your password, change it anyway as a belt-and-suspenders step, and re-enable two-factor authentication if it got turned off (some hijacks disable it to make it easier to get back in). Check for anything the attacker may have set up for persistence, such as new forwarding rules in email, new recovery phone numbers or emails, or new devices added elsewhere — a hijacked session is often used to plant a second foothold before the first one is discovered. Finally, if the compromised account is one contacts trust (like WhatsApp), give people a heads-up that messages from you in the recent past — especially anything asking for money, votes, or codes — may not have been from you.

A travel-specific trap worth flagging

If you're connecting to hotel, airport, or conference Wi-Fi and the captive portal page asks you to "sign in" to Microsoft, Google, or a similar account, or shows you a device code to enter, be suspicious by default — legitimate hotel Wi-Fi almost never needs you to authenticate a personal cloud account to get online. Close the browser, connect through your phone's cellular hotspot or a VPN instead, and if you must use hotel Wi-Fi, avoid logging into anything sensitive on it at all.

One more nugget, if you write or publish code

The same "it's not your password, it's your session/token" logic applies to developer credentials. A recent supply-chain incident involving a poisoned npm package specifically watched for credential rotation and could trigger on it — meaning the instinctive first move (rotate your tokens) was, in that case, the wrong first move. If you ever suspect a build or CI credential has been exposed, check what the compromised package actually did before rotating anything, rather than assuming rotation alone closes the door.

Put it on a calendar

None of this is a one-time fix — it's a habit, the same way checking your bank statement is a habit. Pick a recurring date (the first of the month works well) and run through the device/session lists above. It's a fifteen-minute check that catches exactly the kind of quiet, password-free takeover that everything else in your security setup is built to miss.