Impersonation — Real-World Examples

Example 1: The $340K Pharma Wire (Yusuf's Case)

Yusuf's investigation at Meridian Pharma revealed a multi-layer attack combining cousin domain registration, display name spoofing, and caller ID spoofing. The AP clerk received an email from "Sarah Chen - CFO Office" — display name showing the CFO's real name and title — but the actual sending address was sarah.chen@pharma-corp-billing.com, a cousin domain registered six weeks prior. The email referenced a real ongoing procurement discussion, sourced from internal emails read through a compromised employee account obtained via credential stuffing and SIM swapping.

When the AP clerk called to verify — good security instinct — the attacker was ready. A VoIP call with caller ID spoofed to show the CFO's real internal extension (4-2287) answered as "the CFO's assistant" and verbally confirmed the wire. The clerk processed the $340,000 transfer.

Detection: The destination bank's fraud monitoring team flagged the new recipient account four days after the transfer. Recovery: $180,000 clawback was possible through rapid bank-to-bank coordination; the remaining $160,000 had already moved through multiple accounts and was unrecoverable.

Key lesson: The verification callback failed because it relied on caller ID — a trivially spoofable identifier. The only reliable callback verification is to an independently sourced number from the company directory, not a number from the email or provided by the incoming caller. The attack also showed how credential stuffing enabling account takeover provided the operational intelligence needed to make the impersonation convincing — the attackers knew details about the procurement process because they had read internal emails for three weeks.

Example 2: 2019 UK Energy CEO Deepfake Voice (€220K)

In 2019, the CEO of a UK-based energy company received what he believed was a phone call from the CEO of his German parent company. The voice was correct — the right German accent, the right speech patterns, the right cadence and vocabulary. The caller urgently requested a €220,000 wire transfer to a Hungarian supplier to close a time-sensitive deal. The UK CEO complied and initiated the transfer immediately.

When he called back to confirm the transaction had been processed, the fraudster called again using the same AI voice, expressing urgency. On the third attempted callback, the connection dropped unusually. Suspicion finally set in. But the funds had already cleared to the Hungarian account and been forwarded through multiple intermediaries. The total recovery was minimal.

The attackers had used commercially available AI voice synthesis technology, trained on publicly available recordings of the German CEO — earnings calls, investor presentations, and conference appearances freely available online. This was the first widely reported instance of AI-generated voice being used to commit financial fraud against a business. The technology required no specialized skill — just publicly available tools and publicly available training audio.

Key lesson: Voice recognition is no longer a reliable authentication factor. AI voice cloning from publicly available audio is accessible with free or low-cost tools. The €220K UK case was the proof of concept; the 2024 $25M Hong Kong case (fake CFO on video conference) showed the technology had extended to video and scaled dramatically. Defense: pre-agreed verbal codewords for sensitive communications; independent written authorization through a second verified channel for all financial transactions above threshold; organizational culture that normalizes pausing to verify regardless of how convincing the caller sounds.

Example 3: Twitter 2020 — Social Engineering and Account Impersonation ($120K in 3 Hours)

In July 2020, attackers gained access to Twitter's internal administrative tools by impersonating IT staff in phone calls to Twitter employees — convincing them to provide their credentials to access "internal systems." The attack compromised 130 high-profile accounts including those of Barack Obama, Joe Biden, Elon Musk, Apple, and others.

Using the compromised internal admin tools (not the public API), the attackers sent tweets from these accounts promoting a Bitcoin scam: "Sending 1000 Bitcoin to anyone who sends 500 first." The tweets appeared to come from extremely high-credibility accounts with verified blue checkmarks — the most convincing possible endorsement on the platform. The scam collected approximately $120,000 in Bitcoin within three hours before Twitter suspended the compromised accounts and blocked new tweets.

A 17-year-old was later identified as the ringleader. The attack succeeded not through sophisticated hacking but through social engineering of carrier-level and platform-level staff — phone-based impersonation of IT support personnel to extract credentials from employees who had no reason to suspect an attacker was calling.

Key lesson: Internal staff impersonation through vishing is as dangerous as external impersonation. Attackers impersonated IT staff, not the account holders. Defense requires IT helpdesks and support staff to have authentication verification procedures for any request involving credential access — never provide credentials or administrative access based on an unsolicited incoming call claiming to be from IT.

Example 4: ARP Poisoning for Internal Lateral Movement

During incident response at a financial services firm, forensic analysis revealed that an attacker who had gained initial access via a phishing email had subsequently deployed ARP poisoning on the internal network segment housing the trading desk workstations. Using an ARP poisoning tool run from the initially compromised machine, the attacker redirected all traffic on the /24 subnet through their controlled machine for approximately 72 hours.

In that window, the attacker captured plaintext credentials from a legacy FTP service still in use for batch report transfers, session cookies from the internal employee portal (which used HTTPS but had incorrectly set cookie flags), and the NTLM challenge-response exchanges from SMB authentication — which could be cracked offline to reveal domain credentials. These captured credentials enabled lateral movement to additional machines, including a privileged workstation used for settlement transactions.

The ARP poisoning was invisible to all endpoint detection tools — no signatures fired, no behavioral alerts triggered. It was only discovered during forensic analysis weeks later when network flow anomalies in the historical data were correlated with the timeline of the initial compromise.

Key lesson: ARP poisoning is a silent, post-access lateral movement technique that requires only LAN access and free tools. It captures anything transmitted in cleartext and can enable credential theft even from encrypted channels through other means. Dynamic ARP Inspection would have dropped the forged ARP replies before they reached other hosts, preventing the MITM. HTTPS with properly configured Secure and HttpOnly cookie flags limits what can be extracted from intercepted TLS traffic.

Example 5: Dynamic ARP Inspection Success Story

A healthcare IT organization deployed Dynamic ARP Inspection after a penetration test demonstrated that an attacker with physical access to a hallway network port could conduct silent ARP poisoning against all workstations on the clinical systems network segment. The penetration tester intercepted VoIP calls, captured nurse login credentials to the electronic health records system, and demonstrated the ability to modify HTTP responses to clinical systems — all within minutes of plugging in.

After the penetration test findings, the organization deployed DHCP snooping on all access switches to build trusted binding tables, then enabled DAI on all access ports. Six months later, a contractor from a third-party IT vendor plugged in a personal laptop to an active network port while performing unrelated cabling work. The laptop, which had been compromised with credential-harvesting malware, immediately began sending gratuitous ARP replies claiming to be the default gateway. Every single forged ARP packet was dropped by the switches before reaching any host. No ARP caches were updated. The attack produced zero results. The switch port violation log alerted the security team within seconds.

Key lesson: DAI works exactly as designed — it validates each ARP packet against the DHCP-learned binding table and drops anything that doesn't match. The control requires no per-host configuration and operates transparently to legitimate traffic. DHCP snooping must be deployed first to build the binding table. The combination prevents ARP spoofing from achieving any effect regardless of how the attacker attempts to deliver the forged packets.