A $400,000 video call that almost worked
In early September 2026, the CEO of the developer platform OpenCode publicly described a scam his team came close to falling for. A "customer" joined a video call and, in real time, wore the face of a well-known technology CEO. The request was ordinary on its surface: raise our API rate limits, and here is the payment. The number attached to it was roughly $400,000. What saved the company was not a piece of software. Someone on the team noticed the domain in the email was a near-lookalike, spotted unusual traffic coming from an unexpected region, and felt the pressure of a manufactured deadline, a story about needing this done before boarding a flight. They stopped, opened a separate channel, and messaged the real CEO on Instagram. The real CEO had never heard of the deal.
We have run enough incident reviews to know that this is the shape most successful fraud takes, and most near-misses too. The technology in the OpenCode case was new. The playbook underneath it was old: impersonate someone with authority, invent urgency, and route the money before anyone thinks to check. What changed is that the impersonation now happens live, on camera, with a face and a voice that hold up under a few minutes of scrutiny.
Why real-time deepfakes changed the economics of fraud
For years, business email compromise worked with plain text. An attacker studied a company, learned who approved payments, spoofed or look-aliked a domain, and sent a convincing email. The defense was reasonable skepticism plus a phone call to confirm. The phone call worked because faking a specific person's live voice was hard and faking their face on a video call was effectively out of reach for the average criminal.
That gap has closed. Voice cloning from a few seconds of public audio is now a consumer-grade capability, and real-time face-swapping on a video call has moved from research demos into fraud kits sold on criminal forums. The most cited public example remains the 2024 case at engineering firm Arup, where a finance employee in Hong Kong was walked through a series of transfers totaling around $25 million after joining a video conference in which every other "colleague," including the CFO, was a deepfake. The OpenCode near-miss shows the same technique aimed at a smaller, faster target: not a wire transfer, but a change to service limits that could be resold or abused.
What the attacker actually needs now
The barrier to entry is lower than most boards assume. An attacker needs a short sample of the target's voice or face, both usually available on conference recordings, podcasts, or social video. They need a plausible pretext, which public org charts and LinkedIn supply. And they need one employee who is helpful, busy, and reluctant to challenge someone who appears senior. None of that requires a nation-state budget. In our engagements across banking and telecom clients in the region, the people targeted are rarely the executives themselves. They are the assistants, finance clerks, and support engineers who hold the authority to act but not always the standing to push back.
The controls that stopped a real attack
It is worth being precise about why the OpenCode attempt failed, because the reasons are repeatable. Three signals did the work.
The first was a mismatch the attacker could not fully hide. The sending domain was a near-lookalike rather than the genuine one, the kind of substitution, a swapped letter or an added word, that a trained eye catches and an automated check catches faster. The second was anomalous network behavior: traffic from a region that did not fit the supposed customer's profile. On its own it proves nothing, but paired with a large financial ask it is exactly the correlation a monitoring team should be watching for. The third was the tell that no deepfake removes, manufactured urgency. The "boarding a flight" deadline exists to collapse the window in which someone might verify.
The single action that ended the attack was out-of-band verification. The team did not reply to the email, and they did not ask the person on the call to confirm their own identity, which a deepfake happily does. They reached the real person through an independent channel they already trusted. That is the whole game. Every control below exists to make that verification routine, fast, and hard to skip.
Building a verification standard for high-value requests
Most organizations have a policy that says "verify unusual requests." Few define what verification means, who is allowed to skip it, and how quickly it can be done under pressure. Vague guidance loses to a convincing call every time. The fix is a written standard that treats certain requests as gated by default.
The trigger should be based on impact, not on how suspicious the request feels, because a good deepfake will not feel suspicious. In practice that means any of the following forces the gate: a payment or refund above a set threshold, a change to bank details or payee records, a change to access rights or service limits, or any request to bypass an existing control. When one of those appears, the person receiving it moves to a defined verification path before acting.
Two ideas hold this together. The first is out-of-band contact: verification happens on a channel the requester did not choose and cannot control. If the request arrived by email or a video call, the confirmation goes to a phone number already on file, not a number supplied in the message. The second is dual authorization for the highest-impact actions, so that no single tricked employee can complete the transaction alone. Some of our clients add a shared verbal passphrase for executive-level requests, rotated periodically, which is trivial for the real person to provide and effectively impossible for an attacker who has only cloned a face.
Where each control fits
Deepfake defense is not one product. It maps cleanly onto frameworks the organization likely already follows, which makes it easier to fund and audit. The table below lines up the practical control with its home in NIST CSF and ISO/IEC 27001, and with the layer it protects.
ControlWhat it stopsFramework anchor
Out-of-band callback on a number already on file
Impersonation over the channel the attacker controls
NIST CSF PR.AC / ISO 27001 A.5.17, A.8.2
Dual authorization above impact thresholds
A single tricked employee completing a transfer
NIST CSF PR.AC / ISO 27001 A.5.3 (segregation of duties)
Payee and bank-detail change lockdown
Silent redirection of legitimate payments
PCI-DSS Req. 7 / ISO 27001 A.8.2
Domain monitoring and DMARC enforcement
Lookalike and spoofed sender domains
NIST CSF PR.DS / ISO 27001 A.8.23
SIEM correlation of financial requests with anomalous traffic
Requests that arrive alongside suspicious network activity
NIST CSF DE.AE / ISO 27001 A.8.15, A.8.16
Recurring social-engineering training and simulations
The pressure that makes people skip the gate
NIST CSF PR.AT / ISO 27001 A.6.3
Technical controls that shrink the attack surface
Verification is the control of last resort, the one that works even when everything upstream fails. Good engineering makes sure most attacks never reach that point.
Start with email authentication. Enforcing DMARC at a reject policy, alongside SPF and DKIM, removes the easiest version of the attack, direct spoofing of your own domain. It does nothing against a lookalike domain, which is why domain monitoring belongs next to it: register the obvious permutations of your brand yourself, and watch for newly registered variants so your team learns about a lookalike before an attacker uses it, not after.
Then give your monitoring something to correlate. The OpenCode team noticed strange foreign traffic because someone was looking. A SIEM that ties a high-value request or account change to concurrent signals, an unfamiliar geolocation, a new device, an impossible-travel login, turns a gut feeling into an alert. Data loss prevention and strict controls around payee records reduce the blast radius if a request does slip through. Phishing-resistant multi-factor authentication, meaning hardware keys or passkeys rather than SMS codes, closes the account-takeover path that often precedes these approaches, because the most convincing impersonation of all is a message sent from the genuine, compromised account.
None of these are exotic. Most organizations own the tools already and have simply not tuned them toward this scenario. Reviewing that configuration is usually the fastest, cheapest improvement available.
The human layer: training that survives a convincing call
Awareness training has a bad reputation because most of it is annual, generic, and forgotten by lunch. Training that actually changes behavior under pressure looks different. It teaches the specific pattern, authority plus urgency plus a request to move money or change access, and it gives employees explicit permission to slow down a senior-sounding person without fear of looking difficult. That permission has to come from the top, or the pressure of the call will win.
The most effective single message we give staff is simple: a real executive will never be angry that you verified. Anyone who resists verification, invokes urgency to skip it, or gets aggressive when asked to confirm through a known channel is showing you the clearest red flag there is. Pair that message with realistic simulations, including voice and, where feasible, video pretexts, and rehearse the escalation path so that reporting a suspicious call is a thirty-second action, not a research project. A control nobody can find under pressure is not a control.
A readiness checklist
If you want to close the gap the OpenCode team happened to catch by instinct, this is the order we recommend working through it.
- Define impact-based triggers that gate a request for verification: payments and refunds above a threshold, payee or bank-detail changes, access and service-limit changes, and any request to bypass a control.
- Write a one-page verification standard specifying out-of-band callback to numbers already on file, and dual authorization above the highest thresholds.
- Add a rotating verbal passphrase for executive-level financial requests.
- Enforce DMARC at reject, and stand up domain monitoring for lookalike registrations.
- Configure your SIEM to correlate financial or access requests with anomalous geolocation, new devices, and impossible-travel logins.
- Move privileged and finance accounts to phishing-resistant MFA.
- Lock down payee and bank-detail records so changes require dual approval and independent confirmation.
- Run social-engineering simulations that include voice and video pretexts, and make the reporting path fast and blameless.
- Rehearse the incident response for a suspected impersonation attempt, including who freezes a pending transaction and how.
How Aydahwa Enterprise Can Help
Aydahwa Enterprise builds this kind of layered defense for organizations in banking, telecom, and critical national infrastructure, sectors where a single approved transaction can carry real consequences. Our work is grounded in the standards this article references, ISO/IEC 27001, the NIST Cybersecurity Framework, PCI-DSS, and CIS Benchmarks, and led by architects who have spent 25 years designing controls that hold up in production rather than only on paper.
A typical engagement starts with a gap review against these frameworks, then a practical program: a verification standard your finance and support teams will actually follow, email authentication and domain monitoring configured correctly, SIEM use cases tuned for exactly the correlations that flagged the OpenCode attempt, and social-engineering training built around real pretexts rather than checkbox slides. You can see where you stand today with our free cybersecurity self-assessment and the cybersecurity readiness checklist. For hands-on delivery, our cybersecurity services and managed IT support teams can implement and run these controls with you. When you are ready to talk specifics, reach out to us and we will map a plan to your environment and your budget.
