Scene 1 — The Wire Transfer
Yusuf got the call on a Tuesday morning. He was the red team lead at Meridian Pharma — hired to think like attackers, run simulated intrusions, and find weaknesses before the real threat actors did. But today the call wasn't about a scheduled engagement. The CISO's message was four words: "We've been hit. Come."
The accounting team had processed a $340,000 wire transfer four days ago. The payment went to a newly registered vendor account. The authorization had come by email — a message that, to everyone in Accounts Payable who saw it, looked completely routine. The sender's display name read "Sarah Chen - CFO Office." Sarah Chen was the real CFO. The email had her title, her professional tone, and contextually appropriate details about an equipment procurement Meridian had been discussing with suppliers for weeks.
Yusuf pulled up the raw email headers. The display name said "Sarah Chen - CFO Office." The actual From: address in the headers — not the name, but the real sending address — was sarah.chen@pharma-corp-billing.com. Not pharma-corp.com, Meridian's real domain. Pharma-corp-billing.com. A completely different domain, registered six weeks ago, set up with its own mail server, designed to look like an internal billing department address to anyone who never checked further than the display name.
This was display name spoofing. The attacker had configured the email's display name field — a free-text field with zero authentication — to show the CFO's real name and title. Most email clients present the display name prominently, in larger text, with the actual sending address in small print beneath it, collapsed, or hidden entirely until the user actively expands the sender details. The AP clerk had seen "Sarah Chen - CFO Office" and processed the request. The real Sarah Chen had never sent that email.
Scene 2 — The Domain Family
Yusuf didn't stop at one domain. He pulled WHOIS registration records and passive DNS data and started mapping the attacker's infrastructure. What he found was a carefully assembled collection of impersonation domains, all registered within an eight-week window from the same registrar, all pointed at the same mail server infrastructure.
Pharma-corp-billing.com was the one used in the wire transfer. But there was a cluster of others. Pharma-corp-ap.com — mimicking an Accounts Payable department. Pharma-corp-secure.com. And one that required a second look: pharma--corp.com, with a double hyphen in the middle. At normal reading speed, in a small-font email header, the double hyphen was easy to miss. These were all cousin domains — lookalike domains registered by the attacker to appear visually similar to the legitimate pharma-corp.com.
One of the domains was more sophisticated. The registered domain characters looked identical to pharma-corp.com at first glance, but when Yusuf inspected the raw byte values, two characters were Cyrillic Unicode code points that visually render identically to their Latin equivalents in virtually all common fonts. This was an IDN homograph attack — using Unicode characters from non-Latin scripts that look identical to ASCII letters to create domain names that appear legitimate to human readers but are technically distinct entries in the DNS. A Cyrillic "a" (U+0430) looks exactly like a Latin "a" (U+0061). A domain name built with the Cyrillic character resolves to a completely different IP address from one using the Latin character. Browsers display punycode warnings for some mixed-script domains, but email clients typically do not.
The investment in domain infrastructure told Yusuf something important about this attacker: this was targeted. Someone had researched Meridian Pharma specifically, identified their domain naming patterns, and built a toolkit of convincing impersonation infrastructure before launching the attack.
Scene 3 — Going Deeper: Network Spoofing
The email investigation was the visible surface. Yusuf's forensics team worked through the network logs in parallel, and what they found changed the scope of the investigation entirely. The attackers hadn't simply sent spoofed emails from the outside. They had been inside first — inside the network of an IoT sensor vendor that had a legitimate VPN connection to Meridian's research systems. This was island hopping: using a trusted third-party organization as a stepping stone to reach the primary target through legitimate inter-network trust relationships.
Once inside the vendor's network with a path to Meridian's internal segment, the attackers had deployed layer 2 techniques. A span port capture that the security team had running for incident detection purposes showed something alarming: a rogue device was broadcasting gratuitous ARP replies at regular intervals.
ARP — the Address Resolution Protocol — is the mechanism by which devices on a local network map IP addresses to MAC addresses. When a workstation needs to send a packet to 10.1.0.1 (the default gateway), it broadcasts an ARP request: "Who has 10.1.0.1?" The gateway responds with its MAC address, and the workstation caches that mapping. The critical weakness: ARP replies have no authentication. Any device on the same network segment can send an ARP reply claiming any IP-to-MAC mapping it wants. The rogue device had sent unsolicited "gratuitous" ARP replies to the entire subnet claiming that the default gateway's IP belonged to the rogue device's MAC address. Every workstation that received those replies updated its ARP cache. All their outbound traffic now flowed through the rogue device — a man-in-the-middle attack conducted entirely through ARP spoofing.
There was DNS manipulation as well. The forensics team found evidence of modified DNS responses reaching the internal resolver for the company's HR portal domain. Traffic that should have resolved to the legitimate portal IP was redirected to an attacker-controlled server hosting a credential-harvesting replica. At least eleven employees had entered their credentials on the fake page before the anomaly was noticed.
Scene 4 — The Phone Call
Yusuf interviewed the AP clerk who had processed the wire. Her account added a layer to the attack that the email evidence alone didn't capture.
"I saw the email," she told Yusuf, "but I was nervous about the amount. It was $340,000. So I asked my supervisor whether I should call to confirm before processing." Her supervisor said yes — good instinct. She picked up the phone to call the CFO's office to verify.
The call was answered by a woman who identified herself as Sarah Chen's assistant and confirmed the wire request. She provided the vendor account details verbally. The caller ID on the AP clerk's desk phone had displayed the CFO's real internal extension: 4-2287. The extension matched what was in the internal directory. The clerk processed the wire.
Caller ID spoofing: the attacker had falsified the calling number displayed to the recipient. SIP-based VoIP calling infrastructure allows the From: header in a SIP INVITE message to be set to any value, and most carriers historically passed this through without verification. The attacker had set their VoIP call's originating number to the CFO's real internal extension. To the receiving phone system, the call appeared to originate from that extension. There was no internal VoIP authentication challenge to verify it.
Yusuf explained STIR/SHAKEN to the board. STIR stands for Secure Telephone Identity Revisited; SHAKEN stands for Signature-based Handling of Asserted information using toKENs. The framework requires originating carriers to attach a cryptographic attestation to calls, signing the caller ID information. Attestation levels indicate how much the carrier has verified: A (Full Attestation) means the carrier has confirmed the subscriber is authorized to use the calling number; B (Partial Attestation) means the carrier knows the customer but cannot fully verify that specific number; C (Gateway Attestation) means the call entered the carrier network at a known point but with no subscriber-level verification. Receiving carriers check the attestation signature. Calls that fail attestation can be flagged or blocked.
The attackers in this case had routed their call through an overseas SIP trunk provider that did not participate in STIR/SHAKEN. The call entered the domestic PSTN through an interconnect gateway with no attestation chain — and the falsified extension it carried was passed through unchallenged to the internal phone system.
Scene 5 — The CEO's Voice
Presenting his preliminary findings to the board, Yusuf wanted to contextualize what had happened to Meridian — not as a unique incident, but as part of a documented escalating trend. He pulled up a case from 2019.
The CEO of a UK-based energy company received a phone call from what sounded exactly like the CEO of his German parent company — the right voice, the right slight German accent, the right speech patterns and cadence, the right way of pausing before key phrases. The German CEO instructed his UK counterpart to urgently wire €220,000 (approximately $243,000) to a Hungarian supplier to close a time-sensitive transaction before the end of the business day. The UK CEO wired the money. The German CEO had never made the call. The voice had been synthesized using commercially available AI voice cloning technology, trained on audio samples taken from publicly available recordings of the real German CEO — earnings calls, conference appearances, investor presentations.
This was the first widely documented case of AI audio deepfake fraud in a business context. By the time Yusuf was presenting to Meridian's board in 2024, the technology had advanced dramatically. Voice cloning tools that once required an hour of sample audio could now produce convincing results from as little as three to five seconds. The services were free or inexpensive. The raw material — audio and video of virtually any public-facing executive — was abundant on YouTube, LinkedIn, company websites, and earnings call archives.
Video deepfakes had followed. In 2024, a finance worker at a multinational firm in Hong Kong authorized a $25 million wire transfer after attending what appeared to be a video conference call with multiple colleagues, including a convincing AI-generated version of the CFO. Every person on the call except the victim was AI-generated. The fraud was only discovered when the employee contacted the real CFO afterward to follow up.
"Voice and face recognition are no longer reliable as trust signals," Yusuf told the board. "When you hear someone's voice or see their face in a call, that is not proof of identity anymore. It is one signal among many, and it is a signal that can be manufactured."
Scene 6 — Account Takeover
Yusuf's forensics team kept digging backward through the timeline. The spoofed email and caller ID had been the final-stage delivery of the attack. Before any of that was possible, the attackers had needed specific inside knowledge — the names and relationships of individuals, the details of the ongoing equipment procurement discussion, the AP process flow. Some of that came from LinkedIn and the company website. But some came from inside a real Meridian employee account that the attackers had compromised six weeks earlier.
Marcus, a vendor liaison in the procurement department, had his Okta credentials compromised via credential stuffing. Log analysis showed the attack clearly: starting one Sunday evening, Marcus's account had experienced a series of failed login attempts from IP addresses in three different US states, distributed across a residential proxy network. The attempts were spaced to avoid triggering rate-limiting — consistent with automated credential stuffing tooling testing username-password pairs harvested from prior data breaches. Marcus had reused a password that had appeared in a breach database from an unrelated service two years earlier.
Eventually, one of the tested credential pairs matched Marcus's current Okta password. The automated tool flagged the successful password — but Marcus's account required SMS-based MFA. The attackers pivoted. They called Marcus's mobile carrier, identified themselves as Marcus using personal details assembled from public records, social media, and data broker databases, and requested a SIM swap — a transfer of Marcus's phone number to a new SIM card they controlled. The carrier's customer service representative processed the request. Marcus's phone went silent, losing service. The attackers received Marcus's next Okta MFA code via SMS and completed the login. They were inside.
Over three weeks, working carefully from Marcus's account, the attackers read internal email threads, mapped the AP workflow, identified the CFO's name and communication style, and gathered the operational context they needed to make the impersonation convincing. The $340,000 wire was not their first attempt — it was the product of three weeks of preparation enabled by that initial account compromise.
The password spraying was a parallel track. Automated tools had also been testing "Spring2024!" against hundreds of Meridian accounts — one attempt per account per day, well under any lockout threshold. Two additional accounts had been successfully accessed through that technique.
Scene 7 — Badge Cloning
The network and email investigation had consumed the first week. In the second week, Yusuf's team turned to physical security. Something in the access control logs had bothered him since the briefing: there were three entries from the past six weeks where the server room corridor had been accessed during off-hours by badge numbers belonging to employees who were elsewhere in the building at the time, verified by camera footage. Someone was using cloned badges.
Meridian used HID proximity cards — the standard 125 kHz cards found in office buildings worldwide. Yusuf explained the vulnerability to the physical security director with a simple demonstration. He pulled out a small device — an RFID reader built into what looked like a large wallet — and asked the director to hold his badge as he normally would, at his hip. Standing at conversational distance, Yusuf activated the reader. Within two seconds, the device had silently read the card credential in full. The director hadn't felt anything. His badge hadn't changed hands. He had no idea it had happened.
HID 125 kHz proximity cards operate on a straightforward principle: when within range of an RF field, the card broadcasts a static credential number stored in its memory. There is no encryption. No challenge-response protocol. No session key negotiation. Just a fixed number, transmitted whenever the card is energized by an RF field from a reader. Any device that can generate that RF field and receive the transmission — available commercially for under $50, or buildable from hobbyist components for less — can silently capture that credential from up to about 30 centimeters away. An attacker with a reader concealed in a bag or jacket can clone badges from passersby in elevators, crowded cafeterias, or lobby security queues. The victim never knows. The clone opens the same doors as the original. Both remain functional simultaneously.
The defense required upgrading to modern cryptographic credentials. MIFARE DESFire EV3, HID SEOS, and similar technologies implement AES encryption and mutual challenge-response authentication — the reader issues a cryptographic challenge, the card must produce a correct cryptographically signed response using keys that never leave the card's secure element. Passively reading the RF transmission during this exchange yields only ciphertext that cannot be replayed or used to create a functional clone. Physical badge holders with RFID-shielding material provide a secondary defense, preventing passive reading when the badge is pocketed or clipped to a lanyard.
Scene 8 — Defense Framework
Yusuf's final recommendations to Meridian covered every layer the attackers had exploited. His core message: impersonation attacks succeed by exploiting trust — and every defensive control targets a different trust vector. There was no single fix. The attack had been multi-layered by design, and the defense had to match it.
Email controls: Deploy DMARC at p=reject on all owned domains, with properly configured SPF and DKIM records. This stops exact domain spoofing — unauthorized servers sending as ceo@meridianpharma.com. Add external sender banners to all inbound email arriving from outside the organization, providing a persistent visual signal that the email is not internal. Proactively register pharma-corp-billing.com, pharma-corp-ap.com, and every other domain combination that looks like the company — set them all to reject all mail. Configure email clients to display the full From: address by default, not just the display name. None of this stops a compromised account; it stops the easier external impersonation techniques.
Phone verification: Establish and enforce an organizational policy: no wire transfer, vendor account change, or sensitive authorization will be acted upon based solely on an incoming phone call, regardless of what the caller ID displays. All such requests must be verified by callback to a number sourced from the official company directory. Brief all finance and AP staff on STIR/SHAKEN limitations so they understand why caller ID is not reliable proof of identity.
Deepfake preparedness: Establish pre-agreed verbal codewords between the CFO and any staff member who might receive authorization requests on the CFO's behalf. Create a written policy that any financial authorization above $50,000 requires independent written confirmation through the company's authenticated email portal in addition to any verbal instruction — voice and video authentication is necessary but not sufficient.
Credential and account security: Eliminate SMS MFA for all finance staff, IT administrators, and executives. Replace with FIDO2 hardware tokens for highest-risk roles, authenticator app TOTP for all others. Place carrier-level SIM lock on all corporate mobile accounts. Enroll all email domains in breach monitoring services. Implement login anomaly detection to flag access from unexpected geographies or at unusual hours.
Network controls: Enable DHCP snooping on all access switches to build the trusted IP-to-MAC binding database. Enable Dynamic ARP Inspection (DAI) on all access switch ports — this drops forged ARP replies that contradict the DHCP binding table, preventing ARP spoofing-based MITM attacks. Enable DNSSEC on all authoritative DNS zones and configure internal resolvers to validate DNSSEC signatures. Deploy ingress filtering to drop packets with spoofed source IPs arriving from external interfaces.
Physical security: Upgrade badge credentials from HID 125 kHz to MIFARE DESFire EV3 or equivalent. Issue RFID-shielded badge holders to all staff. Enable anti-passback rules in the access control system. Establish a challenge-anyone-without-visible-badge policy and make it explicit that challenging unfamiliar faces is a security requirement, not a rudeness.