Module 2.4 — The Vishing Kill Chain and Workflow-Gap Detection

50-minute lecture · Day 2 afternoon · Hands-on Sigma rule in the lab

Learning objectives

By end of this module, students can:

  1. Map the AI-enabled vishing kill chain from pre-call recon through wire-transfer execution
  2. Cite the 2025-2026 regulatory mandates for out-of-band verification (Singapore MAS SRF, EU Verification of Payee under PSR/PSD3, US ISO 20022 migration)
  3. Build the workflow-gap SIEM detection as a Sigma 2.0 correlation rule that catches wire transfers proceeding without out-of-band verification within 24 hours
  4. Articulate why workflow-gap detection has higher fidelity than artifact-level detection for the deepfake-BEC threat class

The vishing kill chain

A modern AI-enabled vishing attack against a corporate finance target unfolds in five stages:

Stage 1: Pre-call reconnaissance

The attacker scrapes public-facing data: LinkedIn org chart, executive bios, recent earnings calls, conference talks, public press releases. The objective is to identify the right intermediary target (the AP director, treasury analyst, junior finance employee with wire authority) and gather enough context to make the impersonation convincing.

Defender signal: anomalous LinkedIn scraping patterns, careers-page enumeration, public-API rate spikes against your social profiles. Hard to act on individually; useful as background context when other signals fire.

Stage 2: Initial contact (text)

The attacker establishes a fake communication channel — typically an unfamiliar WhatsApp number, Slack DM from outside the trust boundary, or email from a lookalike domain. The first message is low-commitment: “I need to discuss something urgent and confidential, can you talk?” The attacker is fishing for engagement and gauging the target’s responsiveness.

Defender signal: new WhatsApp / external contact pattern, lookalike domain detection, sentiment-analysis flag on urgency keywords. Module 1.5 covered the email-content side of this.

Stage 3: The voice call

Voice cloning generates the audio in real-time. The attacker claims to be the CEO/CFO/senior executive. Specific scenarios reported in 2024-2026:

The voice is convincing enough that humans without deepfake-detection technology cannot reliably distinguish it from the real executive’s voice. Module 2.2’s detection techniques may or may not catch it (Module 2.2’s lab specifically tests a deepfake that scores below threshold).

Defender signal: Module 2.2 audio detection (variable confidence); call-metadata anomalies (new SIP path, no historical caller-ID pairing for the executive number); workflow-gap signal at Stage 4 (the high-fidelity one).

Stage 4: The instruction handoff

The attacker provides a specific action: “send the wire to this account immediately, before market close.” The instruction asks the target to bypass normal verification workflows — “this is confidential, don’t loop in legal” or “the normal process is too slow.”

This stage is where the workflow-gap detection fires highest. The attacker explicitly asks for verification to be skipped. If the target complies and modifies payment instructions without invoking out-of-band verification, the SIEM signal is the absence of the OOB-verification event within the expected window.

Stage 5: Post-execution

Once the wire is sent, the attacker disappears. Funds move through one or more intermediate accounts before final cashout. The window for recovery is short.

Defender signal: wire-transfer event detected by SIEM; transaction-velocity anomaly; lookup against known-fraudulent receiving accounts (if intel feed exists).

The Arup case (Module 2.1) walked this exact kill chain. The control failure was at Stage 4: payment instructions were modified across 15 transfers without out-of-band verification. The SIEM should have caught the first or second transfer based on the missing OOB event.

The 2025-2026 regulatory environment

Financial regulators globally have started mandating out-of-band verification for wire transfers in response to the BEC surge. The current state as of May 2026:

Singapore — Monetary Authority of Singapore (MAS) Shared Responsibility Framework

Effective July 2025, the MAS SRF mandates out-of-band verification (such as verified callback to a known phone number) for any request to change banking details or any high-risk wire instructions. Liability shifts between bank and customer based on whether the SRF process was followed. Reference: mas.gov.sg, “Shared Responsibility Framework for Phishing Scams.”

Notification timeline for incidents: 3 hours from discovery for significant fraud affecting critical systems (MAS Notice 644).

European Union — Payment Services Regulation (PSR) and PSD3

The EU’s PSR and PSD3 mandate a Verification of Payee (VoP) service, effective June 2026. Banks must verify that the payee’s name matches the IBAN before executing the transfer; if they don’t match, the payment is held for additional verification.

This is name-matching, not full identity verification, but it disrupts the “send the wire to this account I’m telling you on the phone” pattern that vishing depends on. The attacker would need to also compromise the account-name registration, which is harder.

United Kingdom — Financial Conduct Authority (FCA) Operational Resilience

The FCA’s operational-resilience principles require firms to report material incidents “without undue delay” (Principle 11). Deepfake-related fraud above firm-specific impact thresholds triggers this requirement.

United States — ISO 20022 wire migration

The US Federal Reserve’s CHIPS and Fedwire migration to ISO 20022 (effective July 2025) mandates structured beneficiary and originator data on all wire transfers. Wires with missing structured data are rejected. This makes “send the wire to this account” instructions harder because the wire infrastructure now requires structured context that the social-engineering script must provide.

United States — FinCEN deepfake alert

FinCEN Alert FIN-2024-Alert004 (November 13, 2024) requires SAR filings on suspected deepfake fraud to be tagged with FIN-2024-DEEPFAKEFRAUD in field 2 of the SAR. Nine specific red-flag indicators provided. Standard SAR filing deadline (30 days from determination, longer for ongoing investigations).

Cross-cutting: NIS2 / DORA (EU financial sector)

For EU financial entities subject to DORA (effective Jan 2025): 24h early warning, 4h classification, 72h full incident report to the supervisory authority for major ICT incidents affecting financial entity operations.

The workflow-gap Sigma rule (Codex-generated)

The detection that catches the Stage 4 failure mode is a Sigma 2.0 correlation rule with two named sub-rules joined by temporal correlation. The pattern: detect a payment-instruction modification AND require an out-of-band verification event within 24 hours. The correlation fires when the modification exists without the verification.

title: Wire Transfer Payment Instructions Changed Without Out-of-Band Verification
id: 8a4f41e0-44fa-4901-9a5c-3c4d30f5c8dc
status: experimental
description: >
  Detects a wire transfer payment instruction modification where the expected
  out-of-band verification event for the same transaction is absent within 24
  hours. The temporal correlation is evaluated with the modification rule as
  the alert anchor.
date: 2026-05-14
logsource:
  product: finance
  service: payments
correlation:
  type: temporal
  rules:
    - wire_transfer_payment_instruction_modified
    - wire_transfer_oob_verification_completed
  group-by:
    - transaction_id
  timespan: 24h
  condition:
    eq: 1
  generate: true
named_rules:
  - title: Wire Transfer Payment Instruction Modified
    name: wire_transfer_payment_instruction_modified
    logsource:
      product: finance
      service: payments
    detection:
      selection:
        event.action: payment_instruction_modified
        payment_method: wire_transfer
        transaction_id|exists: true
      condition: selection
  - title: Wire Transfer Out-of-Band Verification Completed
    name: wire_transfer_oob_verification_completed
    logsource:
      product: finance
      service: payments
    detection:
      selection:
        event.action: out_of_band_verification_completed
        payment_method: wire_transfer
        transaction_id|exists: true
      condition: selection
fields:
  - transaction_id
  - payment_instruction_modified_at
  - oob_verified_at
  - employee_id
  - target_account
  - amount_usd
falsepositives:
  - Emergency vendor bank-detail changes where verification is documented in a separate case-management system.
level: high
tags:
  - attack.initial_access
  - attack.t1566.004

Why this beats artifact detection

The artifact-level controls (audio detector, video detector, anomaly-on-domain) all face the same problem: adversary capability is advancing faster than detection capability. The workflow-gap detection inverts this:

Tuning the 24-hour window

24 hours is a defensible default. Calibrate for your environment:

Known false-positive scenarios

  1. Emergency vendor bank-detail changes verified through a separate case-management system the SIEM doesn’t ingest → mitigate by integrating the case-management system or suppressing specific documented exception codes
  2. Batch payment runs where individual transactions don’t have per-transaction OOB events → mitigate by adjusting group-by to batch-level
  3. Legitimate self-service portal changes where the verification happens at portal-login rather than per-transaction → mitigate by extending the rule to recognize portal-auth events as equivalent

A SOC deploying this rule should run it in shadow mode for 30 days before alerting, calibrate against the documented false-positive scenarios, then promote to alerting.

Real-world cases the rule would catch

Cases where workflow-gap detection succeeded

Cases where the rule’s absence allowed loss

Cases where regulation is now mandating the rule

The regulatory direction is clear: out-of-band verification is becoming mandatory infrastructure, not optional control.

Detection-engineering deliverable

For students leaving Day 2, the deliverable is:

  1. The Sigma rule above, adapted to your SIEM’s data model (Splunk, Sentinel, Chronicle, etc.)
  2. A documented 30-day shadow-mode plan to calibrate against your environment’s false positives
  3. Integration with your case-management system to suppress documented exception codes
  4. An alert routing decision: when the rule fires, the alert goes to which tier (Tier-1 vs Tier-2 vs incident response), and what playbook the responder runs (Module 2.6 covers the IR playbook)

This deliverable is architectural, not technological. It does not depend on which audio detector you chose in Module 2.2 or whether your platform supports C2PA from Module 2.3. It works regardless of artifact-level detection capability.

Discussion questions (~10 min)

  1. Your org’s wire transfers go through an internal portal that records both “payment instruction modified” and “approval completed” events. Approval is performed by a separate analyst (not the modifier). Is the second-analyst approval functionally equivalent to OOB verification for the workflow-gap rule? Why or why not?
  2. The EU’s Verification of Payee under PSR/PSD3 (Jun 2026) checks name-matching at the wire infrastructure level. Does this make the workflow-gap SIEM rule redundant for EU operations? What residual risk remains that the SIEM rule still catches?
  3. A senior executive complains that the OOB verification step is “slowing down legitimate business.” How do you defend the control to leadership using the cases from Module 2.1 + 2.4?

Common mistakes

MistakeBetter approach
Static 24h window for all transaction typesTune per channel: shorter for real-time wires, longer for cross-border
Group-by on individual transaction when batches are commonAdjust group-by to match your payment-batching model
Deploying the rule in alert mode immediatelyShadow mode for 30 days first; calibrate against documented FPs
Treating the rule as a substitute for the audio/video detectorsLayered defense: artifact detection + workflow-gap is stronger than either alone
Ignoring the case-management system’s exception codesIntegrate so legitimate exceptions don’t trigger alerts

What’s next

Module 2.5 extends the deepfake threat class to synthetic identity — AI-generated executive profiles, KYC bypass, fake vendor onboarding. Same workflow-gap thinking applied to identity-verification workflows.