Impersonation — Tricks & Performance Tasks

FALSE — DMARC authenticates the domain in the From: header address but does NOT prevent display name spoofing.

DMARC with a reject policy is a powerful and essential control. It stops one specific attack: exact domain spoofing — an unauthorized mail server trying to send email that claims to be from ceo@company.com. If the sending server's IP is not in the SPF record, and the email lacks a valid DKIM signature from the real domain, DMARC with reject policy blocks delivery. This is valuable.

But display name spoofing is completely different. In display name spoofing, the attacker sets the visible display name field to "Sarah Chen - CFO" and sends from sarah.chen@pharma-corp-billing.com — a domain the attacker registered and controls. DMARC on pharma-corp.com has absolutely no jurisdiction over pharma-corp-billing.com. The attacker configures their own SPF, DKIM, and DMARC records for their domain. All authentication checks PASS — because the email genuinely came from the authorized sender for pharma-corp-billing.com. DMARC on the real domain is irrelevant.

What DMARC does NOT stop:
— Display name spoofing (different domain entirely, DMARC has no authority)
— Cousin domain attacks (same principle — different domain, attacker controls their own DNS)
— Compromised account abuse (the email IS from the real account, everything passes)

What DMARC DOES stop:
— Exact domain spoofing (unauthorized server claiming to be from the real domain when SPF/DKIM fail)

Defense against display name spoofing: Train users to look at the actual email address, not just the display name. Configure email clients to show full From: addresses prominently by default. Add [EXTERNAL] banners to all inbound email. The human layer is the defense here — there is no technical protocol that prevents an attacker from setting their display name to any value they choose.

Exam tip: Any answer that says DMARC "prevents all email impersonation" or "prevents display name spoofing" is wrong. DMARC is essential but narrowly scoped to exact domain spoofing only.

FALSE — STIR/SHAKEN significantly reduces robocall spoofing on domestic US calls but cannot prevent all caller ID spoofing scenarios.

STIR/SHAKEN requires participating carriers to cryptographically sign caller ID information. It has been effective at reducing mass robocall spoofing — calls where attackers claim to be calling from IRS numbers or bank fraud lines at scale. For those scenarios, STIR/SHAKEN provides meaningful reduction in spoofed calls reaching consumers.

What STIR/SHAKEN cannot prevent:

(1) Calls originating overseas: Foreign carriers are not subject to FCC STIR/SHAKEN mandates. A call placed through a SIP trunk from a provider in another country and entering the US PSTN via an international gateway can carry any caller ID the attacker chooses, and that number passes through with C-level (gateway) attestation or no attestation at all — because the US carrier receiving it at the gateway simply doesn't know who placed the original call.

(2) Unregistered or non-compliant SIP trunks: Not all SIP providers have fully deployed STIR/SHAKEN. Attackers can route calls through providers that don't participate, entering the PSTN through carriers that pass calls without full attestation chains.

(3) A-level attestation doesn't prove innocence: Even the highest attestation level (A) means the carrier verified that the subscriber is authorized to use the calling number — it does not prove the subscriber isn't an attacker. A criminal who legitimately owns a VoIP number and calls it their business line has A-level attestation for that number. They can then claim to be anyone.

(4) Internal PBX spoofing: In enterprise environments, internal extensions can sometimes be spoofed through the organization's own PBX before STIR/SHAKEN is applied at the carrier level — relevant to internal impersonation scenarios like Yusuf's case where the CFO's internal extension was displayed.

Exam tip: "STIR/SHAKEN eliminates" = FALSE. "STIR/SHAKEN reduces" = TRUE for domestic mass robocall spoofing. The defense policy implication: treat caller ID as an indicator, not proof of identity, regardless of STIR/SHAKEN attestation level. Callback verification to an independently sourced number remains essential.

TRUE — and this limitation is important to understand.

ARP operates at Layer 2 (the Data Link layer). ARP messages are broadcast frames — they are addressed to the broadcast MAC address (FF:FF:FF:FF:FF:FF) and are received by all devices on the same broadcast domain. Routers do not forward ARP broadcasts — they terminate at the router interface. ARP messages literally cannot cross from one subnet to another without being routed, and routing would require re-encapsulation as a different protocol entirely, which doesn't happen for ARP.

This means: an attacker performing ARP spoofing can only intercept traffic on the same Layer 2 broadcast domain where their device is connected. An attacker on VLAN 10 cannot ARP-spoof traffic between hosts on VLAN 20. An attacker on the internet cannot ARP-spoof your internal LAN.

Practical security implications:

(1) Network segmentation limits blast radius: If the network is divided into many small VLANs with limited hosts per VLAN, a successful ARP poisoning attack is limited to the attacker's segment — they cannot intercept traffic on other VLANs without first pivoting there. Smaller broadcast domains = smaller ARP poisoning scope.

(2) ARP spoofing is an insider or post-access technique: Because the attacker must be on the same LAN segment, ARP spoofing is primarily a threat from: malicious insiders with physical or logical LAN access; attackers who have already compromised one machine on the network (post-foothold lateral movement); rogue physical devices plugged into exposed network ports. It is NOT a remote initial access technique from the internet.

(3) DAI provides segment-wide protection: Because ARP is contained within a broadcast domain, Dynamic ARP Inspection deployed on the switches of a segment provides complete protection for that entire segment — no hosts within the segment can be ARP-spoofed by any other device on the same segment, regardless of position.

Exam tip: "ARP spoofing can be performed remotely across the internet" = FALSE. "ARP spoofing requires LAN access / same broadcast domain" = TRUE. "Network segmentation limits ARP attack scope" = TRUE.

FALSE — this describes a dictionary or brute force attack, not credential stuffing.

Credential stuffing uses username/password PAIRS from prior breaches — the attacker tests the SAME specific credential combination (username + its known password from a breach database) across many different services. The attack exploits PASSWORD REUSE: if user@email.com used "Fluffy2018!" at a breached social media site, the credential stuffer tests that exact combination — user@email.com / Fluffy2018! — against banks, email providers, gaming platforms, and other services. The attacker isn't guessing passwords; they already know this specific user's password from the breach. They're just testing whether the user reused it elsewhere.

Comparison of attack types:

Credential stuffing: Many different users × their specific known passwords from breaches. Testing exact breach-sourced pairs. Works because of password reuse. Requires a breach database.

Password spraying: Many users × one or a few generic common passwords ("Password1!", "Summer2024!"). Deliberately slow — one or two attempts per account. Designed to avoid lockout. Works because some users always have weak passwords.

Dictionary attack: One user × many passwords from a wordlist (common words, patterns, variations). Faster than brute force, targeted at one account. Will trigger lockout if not rate-limited.

Brute force: One user × exhaustive combinations (all possible character sequences up to a length). Triggers lockout quickly on live systems. Effective offline against password hash databases.

The key differentiator for exam purposes:
— "Pairs from a prior breach" = credential stuffing
— "Common passwords across many accounts" = password spraying
— "Many passwords against one account" = brute force or dictionary

Exam tip: Watch for questions that describe the technique — "using a breach database of username/password pairs" → credential stuffing. "Trying 'Password1' against 10,000 accounts" → password spraying. "Trying 1,000 password variations against one account" → dictionary/brute force.

FALSE — modern voice cloning tools can produce convincing results from as little as 3–5 seconds of audio.

This misconception leads organizations to underestimate the threat. Early voice cloning systems (circa 2018–2020) did require substantial training audio — sometimes 30 minutes or more — to produce passable results. Those requirements have collapsed. By 2023–2024, commercially available voice cloning services (ElevenLabs, Resemble.ai, and others) required only a brief audio sample to generate convincing voice replicas. The 2019 UK energy CEO attack, which was the first documented case of AI voice fraud, used what was then considered a relatively short sample from public earnings calls — far less than an hour of audio.

Why the sample requirement matters for threat assessment:

(1) Public figures have abundant training material: Any CEO, CFO, board member, or executive who has given investor calls, conference presentations, media interviews, keynote addresses, or YouTube appearances has provided more than sufficient voice training material for a convincing clone. This material is publicly available, free, and often high audio quality.

(2) Even private individuals are vulnerable: Voicemail greetings, social media videos, TikTok clips, and short video calls provide enough material for modern tools. A voice clone of a non-public employee is achievable from a few minutes of audio.

(3) The technology is free or cheap and requires no technical skill: Web-based voice cloning services allow anyone to upload a voice sample and generate synthetic speech with no technical knowledge. The barrier to entry is near zero.

Why this matters for defense:
The inadequacy of voice recognition as an authentication signal is not a future concern — it is a present reality. Organizations that rely on "I recognize the voice" as a security control for financial authorization are already inadequately defended. Process controls are required now: pre-agreed codewords, out-of-band verification through a second channel, written authorization requirements for large transactions.

Exam tip: "Deepfake voice requires extensive training audio" = FALSE. "Deepfake voice can be created from brief public recordings" = TRUE. The 2019 UK case (€220K) used commercially available tools and public audio — this is the canonical exam example.

Layered Anti-Impersonation Control Framework for Finance Wire Transfer Protection:

Technical Email Controls:
Deploy DMARC at p=reject on all organizational domains — this stops exact domain spoofing. Configure SPF records listing all authorized sending servers and DKIM signing on all outbound email. Register all obvious cousin/typo domain variants of the organization's domain (e.g., organization-billing.com, organization-ap.com, organization-finance.net) and configure them to reject all mail — this prevents attackers from using those domains even if they try to register them proactively. Configure the email gateway to add a prominent [EXTERNAL] banner to all inbound messages not originating from internal infrastructure — provides a persistent visual signal that an email claiming to be from internal staff is actually arriving from outside. Enable email header inspection settings so all email clients display the full From: address by default, not just the display name — removes the display name spoofing hiding place. Deploy AI-based behavioral email security (Abnormal Security, Proofpoint, etc.) that detects anomalous request patterns, unusual urgency language, and first-time sender + wire request combinations.

Authentication Controls:
Eliminate SMS-based MFA for all finance staff, IT administrators, and executives — replace with authenticator app TOTP at minimum. Deploy FIDO2 hardware tokens (YubiKey) for the highest-risk roles: AP clerks who process wires, CFO and executive staff, finance leadership. FIDO2 tokens are phishing-resistant — credentials are cryptographically bound to the legitimate site and cannot be captured by phishing proxies. Place carrier-level SIM lock (port freeze, verbal PIN required for account changes, store visit for SIM replacement) on all corporate mobile accounts for finance and executive staff — this prevents SIM swapping as a vector for bypassing authenticator app MFA. Require re-authentication for any wire transfer initiation regardless of session state — this limits the damage window if a session is somehow compromised.

Process Controls — Wire Transfer Authorization:
Dual authorization required for all wires above $25,000 — two separate authorized individuals must approve, through separate authentication sessions, before initiation. Out-of-band callback mandatory for: any new vendor setup, any change to existing vendor banking details, any wire request above $50,000. The callback must use a phone number from the original vendor contract documentation or the organization's independently maintained vendor directory — NOT the number in the email requesting the wire, NOT the number the requester provides during the call, NOT a number found by searching online at the time of the request. If any of those three "not" conditions are violated, the wire is held until independent number verification is completed. New vendor setup requires signed paperwork with two management approvals and a 5-business-day hold before first wire — no urgent new vendor wires regardless of business justification provided via email or phone. Verbal authentication codewords established with CFO and finance leadership for use in phone and video authorization of large transactions — any caller who cannot provide the codeword fails voice verification regardless of other indicators.

Caller ID and Deepfake Awareness:
Train all finance staff that caller ID is not reliable proof of identity — provide specific training on STIR/SHAKEN limitations and how caller ID spoofing works. Include the 2019 UK CEO deepfake case and 2024 Hong Kong case in security awareness training to establish that voice and video are no longer trustworthy authentication signals. Document in policy: no financial transaction authorization will be acted upon based solely on an incoming voice or video call, regardless of how convincing the caller appears.

Network Security (Defense in Depth):
Enable DHCP snooping and Dynamic ARP Inspection on all access switches — prevents ARP spoofing-based MITM on internal LAN segments. Enable DNSSEC on all authoritative zones; configure resolvers to validate DNSSEC. Deploy DNS over HTTPS or DNS over TLS to prevent DNS interception. Enforce HTTPS with HSTS on all internal applications to ensure intercepted traffic is encrypted and unreadable.

Awareness and Detection:
Monthly targeted security awareness simulations for finance staff — focus specifically on wire transfer fraud scenarios, cousin domain email identification, and caller ID spoofing recognition. Set up alerts for new domain registrations containing the organization's name (DomainTools, SecurityTrails, or BrandShield monitoring). Monitor login anomalies on all finance staff accounts — geographic outliers, time-of-day outliers, new device logins. Publish wire transfer metrics quarterly to leadership: attempted fraud incidents, successful verifications, near-miss catches.

Incident Response — If a Wire Goes to Wrong Account:
Immediately contact the sending bank — wire recall requests must be initiated within hours to maximize clawback potential. Clawback success rates drop sharply after 24 hours as funds move through intermediaries. Contact the destination bank simultaneously through the FBI's Financial Fraud Kill Chain initiative if the destination is domestic. File with FBI IC3 (Internet Crime Complaint Center) within 72 hours — this is required for access to FBI-mediated bank coordination. Preserve all email headers, phone records, and authentication logs immediately — do not allow systems to auto-purge logs during the investigation window. Conduct a full post-incident review identifying every control that was bypassed and update the framework accordingly.