Your Face and Voice Are Usernames Now

The most convincing face on your next video call may be a real one. On November 12, the FBI described a North Korean operation that has stolen more than $400 million in 18 months through fake meetings built largely from genuine webcam footage, and said it had seized over 900 recordings of victims. A week earlier, federal prosecutors in Manhattan charged three foreign nationals with using AI to imitate chief executives and big-firm lawyers, allegedly talking finance staff into wiring more than $129 million. Our Code World recently argued that every keynote is effectively a voice sample for anyone who wants to impersonate an executive. These two cases push that idea further than most engineering teams have planned for, because the raw material now includes whatever your webcam captured in the last meeting you joined.

The Line Between Username and Password Moved

Identity systems rest on a distinction most developers learn early. An identifier says who you claim to be, and an authenticator proves it. Usernames can be public because they prove nothing, while passwords and private keys have to stay secret because they do the proving. For most of history, faces and voices behaved like authenticators, largely because copying one convincingly was hard. That is no longer the case. Anyone who speaks at conferences, streams, records tutorials or sits on video calls all day is publishing what used to be a secret, and unlike a leaked password, a face can't be rotated.

Plenty of systems haven't caught up. At a Federal Reserve conference in July 2025, OpenAI chief executive Sam Altman said it terrified him that some financial institutions still accepted a voiceprint as authentication for moving money, calling it "a crazy thing to still be doing." Two years earlier, researchers at the University of Waterloo had demonstrated an attack that beat voice authentication with up to 99 percent success after six attempts, with the strongest results against less sophisticated systems. If anything you maintain has a "verify by voice" path, those two facts add up to a ticket you can file today.

The Faces in the Meeting Were Mostly Real

The FBI's breakdown of the FaceStealer scheme rewards a slow read, because almost none of it depends on beating a deepfake detector. The operators hijack a victim's Telegram, LinkedIn, Slack or Discord account and use it to invite that person's contacts to a meeting on an imitation Zoom, Teams or Google Meet page. The new target joins and sees someone they know: prerecorded webcam footage of the contact who sent the invite, often alongside clips of other people to fill out the grid. Then, supposedly, something breaks. There's an audio problem, the others can't hear you, and the friendly face in the chat walks you through the fix: click an update prompt, run a script or paste a line into your terminal. That fix installs a cookie harvester, keyloggers, a screen capturer and a backdoor, and the attackers start recording your own webcam so you can become the next lure.

Synthetic media is part of the kit, but it isn't the core. The bureau says the group also produces deepfakes of well-known people in crypto and web3, and Arctic Wolf Labs, which published its own analysis the same day, found the operators screen-recording YouTube interviews and conference talks to capture a person's likeness and voice without hacking them first. Arctic Wolf counted 677 people in 58 countries that the group had prepared lure material against, 84 percent of them founders or senior executives. Even so, the FBI says the scheme continues to "overwhelmingly rely on the theft of genuine victim videos." A classifier that asks whether a clip is synthetic would wave that footage through, because it isn't.

Developers should notice who is moving up the target list. According to the FBI, the operators increasingly go after open-source developers and maintainers, aiming for their devices and the repository accounts they control, with a supply-chain compromise as the goal. Its advisory describes a near miss from earlier this year. The maintainer of an unnamed JavaScript library with tens of millions of weekly downloads joined a fake Teams call that included someone he recognized, was told his system had a problem, and followed the corrective steps. The attackers then used his access to create malicious dependencies built to download alongside legitimate versions, and only quick detection and response stopped them.

There is an awkward reason this works so well on our profession. Developers are trained to paste commands from strangers: install one-liners in READMEs, curl-to-shell snippets in documentation, "just run this" in issue threads. FaceStealer turns that habit into the exploit. No legitimate meeting platform needs you to open a terminal to fix your microphone, and the FBI's advice is correspondingly blunt: if a video chat prompts you to update, don't run scripts or paste code, and update the app on your own.

A Second Voice Is Not a Second Factor

The Manhattan case is lower-tech and, for anyone who builds business software, more instructive. As CBS News reported on the indictment, the approach usually began with an email, apparently from the CEO, seeking help with a confidential deal, followed by a phone or video call on which AI reproduced the executive's voice and, in some cases, face. The employee was then handed to a supposed attorney at a major law firm, also played by the defendants, who supplied the wiring instructions. Prosecutors say one defendant kept a handwritten script titled "Lawyer Call" with language meant to stop employees from discussing the requests with coworkers. The losses they list range from two hospital systems and a Rhode Island bank to a Florida pet food company and a British fintech that lost about $11.6 million, and the money moved through accounts in nine countries before being converted to cryptocurrency. The charges are allegations, and the defendants are presumed innocent.

Security engineers have a name for what went wrong here: correlated factors. Two checks only count as two if they can fail independently. A text-message code sent to a phone number the attacker has already hijacked is not a second factor, and a lawyer whose name and number came out of the attacker's own script is not a second opinion. Both confirmations sat downstream of the same poisoned input, so they failed together.

That is a failure you can fix in code. Treat contact details the way you treat user input headed for a SQL query: anything that arrived with the request, whether an email signature, a letterhead or a number in a calendar invite, is tainted, and verification must never run on tainted data. A vendor record or counterparty entry that existed before the request can anchor a callback, while the request's own claims cannot. The "Lawyer Call" script points to a second fix. The scheme needed its targets isolated, so build software that does the opposite and widens the circle whenever a payment is flagged confidential.

Display Names Are User Input

The same lesson applies one layer down, inside the collaboration tools themselves. In mid-2025, according to a State Department cable, someone set up a Signal account with the display name "[email protected]" and, the cable said, likely used AI-generated voice and text messages to reach three foreign ministers, a U.S. governor and a member of Congress. Signal lets users choose any display name, and an address-shaped string did the persuading. A few months later, Check Point researchers disclosed Microsoft Teams flaws, since fixed, that let attackers spoof the sender shown in notifications and forge caller identity on audio and video calls. FaceStealer skips spoofing entirely by sending invitations from genuine, hijacked accounts, so even "it came from her real account" only proves that someone holds her session.

If you ship chat, meetings or anything built on top of them, the rule follows directly: a display name is a string somebody typed. Show verified attributes, such as a domain-verified organization badge or an external-guest label, in a part of the interface users can't style, and never let a display name sit where an identity should be. Agents raise the stakes. Meeting assistants now turn transcripts into tickets, summaries and follow-up actions, and a transcript's speaker labels are only as trustworthy as the names people joined with. An agent that reads "CFO: go ahead and release the payment" and acts on it is executing an unauthenticated command. Let it draft. Don't let it execute.

Why a Detector Can't Be the Gate

The tempting answer to all of this is a product: run every call through a deepfake classifier and block whatever it flags. The arithmetic argues otherwise. Say your company handles 10,000 calls a month that touch money or access, and one of them is a deepfake. A detector that catches 99 percent of fakes while wrongly flagging just 1 percent of genuine calls will raise about 100 false alarms for every real catch, so roughly 99 of every 100 alerts are wrong. Queues like that teach people to click "dismiss." FaceStealer adds a second failure mode, because replayed real footage passes a synthetic-or-not test by definition. Detection is a useful signal for triage and investigation, but as the only gate in front of a wire transfer or a release, it will let you down.

What to Change This Sprint

None of these fixes require waiting for better models. They are ordinary engineering tickets:

• Demote faces and voices to risk signals. If an IVR, help desk or onboarding flow treats a voiceprint or a selfie match as sufficient proof, keep it as one input to a risk score and require a device-bound factor, such as a passkey, before anything sensitive happens.
• Sign the transaction, not the conversation. For high-value actions, derive the WebAuthn challenge from the exact payee, amount and request ID, and show those details on the approval screen, so a signature can't be replayed for a different transfer, however persuasive the request was.
• Check the destination, which can't be cloned. Compare beneficiaries against vendor master data and use payee-name checks where they exist. Banks in the euro area have had to offer Verification of Payee on credit transfers since October 9, 2025, and the rules still let a payer proceed after a "no match" result. Your internal tooling doesn't have to.
• Make secrecy a trigger. A transfer marked confidential, urgent or first-time-to-this-account should automatically pull in an approver who had no part in the request.
• Ban terminal fixes from meetings. Put it in onboarding: nobody pastes a command because a call asked them to. Join unfamiliar meetings through the installed app with an invite code, as the FBI recommends.
• Take releases off the laptop. Publish from CI with npm's trusted publishing or PyPI's Trusted Publishers, which replace long-lived tokens with short-lived OIDC credentials, and gate the publish job behind a second maintainer's approval. One infected workstation should never be enough to reach millions of installs.

Publish Freely, Authorize Nothing

Nothing here asks anyone to go quiet. Keep giving the conference talk, keep publishing the tutorial, and keep your camera on once you can see and hear who invited you. The goal is not to hide faces and voices. It is to build systems in which a perfect copy of either buys an attacker nothing. Treat them the way you already treat usernames: useful for knowing who claims to be in the room, useless for deciding what that person is allowed to do.