Module 2.6 — IR Playbook: Deepfake-Suspected Incident

50-minute lecture · Day 2 afternoon · Lab follows

Learning objectives

By end of this module, students can:

  1. Execute the first 30 minutes of IR for a deepfake-suspected incident: preserve audio/video artifacts, freeze the source channel, OOB-verify with the impersonated party, hold financial transactions
  2. Cite the regulatory notification timelines for: US FinCEN SAR (with FIN-2024-DEEPFAKEFRAUD keyword), EU NIS2/DORA (24h early warning, 4h DORA classification, 72h full report), UK FCA (without undue delay), Singapore MAS (3h from discovery)
  3. Coordinate transaction reversal windows: FBI IC3 RAT filing (golden hour first 4 hours, viable 0-48h), SWIFT R-message/MT192 (optimal within 24h, drops sharply after 48h), Hold Harmless Agreement submission (parallel to IC3)
  4. Apply forensic preservation discipline (multi-algorithm hashing, native-container preservation, metadata extraction, immutable chain-of-custody) suitable for insurance/litigation

The first 30 minutes

When a deepfake-suspected incident is reported, the SOC has a small window to take actions that materially change the outcome. The playbook for the first 30 minutes:

Minute 0-5: Triage and triage decision

Minute 5-10: Preserve artifacts

Minute 10-15: Freeze the channel

Minute 15-20: Out-of-band verification with the impersonated party

Minute 20-30: Financial holds

Regulatory notification timelines

The applicable notification regime depends on jurisdiction and incident type. Major windows the SOC should know:

US — FinCEN SAR

US — State breach notifications (NY SHIELD, CA SB 446, etc.)

EU — NIS2 (broad ICT incidents)

EU — DORA (financial sector)

UK — FCA Principle 11

Singapore — MAS Notice 644

The detection engineer’s job: pre-build the notification trigger logic in your SIEM so that the right SAR/regulatory-notification queue is auto-populated when the incident-type criteria are met. Manual translation of “we have an incident” → “what notifications do we need to file” is too slow when the shortest window is 3 hours.

Transaction reversal coordination

If financial harm has occurred, the SOC’s job pivots from prevention to recovery. The viable channels and their windows:

FBI IC3 Recovery Asset Team (RAT)

SWIFT R-message (MT192) or recall

Hold Harmless Agreement

The integrated recovery playbook the SOC runs in parallel during hour 1-4 post-incident:

Hour 0-1: IR triage, preserve artifacts, freeze channels, OOB-verify
Hour 1-2: File IC3 RAT, initiate SWIFT R-message, prepare Hold Harmless
Hour 2-4: Coordinate with receiving bank (via your bank's relationship)
Hour 4-24: Continue follow-up; transition to formal SAR filing track
Hour 24+: Insurance claim notification, legal coordination, post-mortem

Forensic preservation discipline

For incidents that may proceed to insurance claim, litigation, or criminal investigation, the artifact preservation steps must satisfy chain-of-custody requirements:

Step 1: Multi-algorithm hashing

Compute SHA-256 and MD5 hashes of every preserved artifact immediately upon acquisition. Store the hashes in an immutable log. This establishes a digital fingerprint that pre-empts later “the file was tampered with” claims.

Step 2: Native container preservation

Do NOT transcode media before analysis. Deepfake detection algorithms rely on pixel-level artifacts and codec-specific noise patterns that are destroyed by re-encoding. Preserve in the original container format (MP4, MOV, WAV) with the original codec.

Step 3: Metadata and provenance extraction

Run exiftool (or equivalent) against the artifact. Capture: creation software identifier, encoder version, frame rate, container metadata, any GPS coordinates, any embedded camera/device identifiers. This often reveals AI tool signatures (FFmpeg pipelines, model tags) and stream-timestamp inconsistencies.

Step 4: Immutable chain of custody

Document who accessed the artifact, when, with what tool, for what purpose. Use write-once storage where available. Insurance claims and litigation outcomes depend heavily on whether chain-of-custody can be demonstrated.

Step 5: C2PA verification if applicable

If the artifact has a C2PA manifest, verify it per Module 2.3’s pipeline. Record the verification result in the evidence log alongside the hashes.

Documented playbook references

Two organizations have published deepfake-suspected-incident playbooks the SOC can adapt:

Both documents are worth pulling for any SOC building or updating its deepfake IR playbook. The detection engineer should adapt these — they’re starting points, not drop-in solutions.

The post-incident phase

Once acute response is complete (typically within 72 hours), the SOC owns several follow-on activities:

  1. Post-mortem: what specifically allowed this incident to reach the action stage? Which controls fired (or should have fired)? What workflow-gap or artifact-detection signal was absent?
  2. Detection-rule update: if the workflow-gap rule from Module 2.4 didn’t catch this, either the rule didn’t exist, the data source wasn’t ingested, or the threshold was wrong. Update accordingly.
  3. Lessons-learned communication: to the rest of the org. The Ferrari case is taught at MIT Sloan because Ferrari published it. Internal sharing of near-misses (with appropriate confidentiality) builds organizational defense.
  4. Regulatory follow-through: the formal SAR, the NIS2 full report, the FCA submission — these all have longer deadlines than the initial notifications. Track them.
  5. Insurance-claim coordination: with hashes, chain-of-custody, and the artifact preservation work from earlier, the claim file is much stronger.

Discussion questions (~10 min)

  1. Your org discovers a deepfake-driven wire transfer of $2.4M at 6:00 PM on a Friday. Walk through the next 24 hours — which actions are time-critical (IC3 RAT? SWIFT recall? FinCEN SAR? state breach notification?), and what does the calendar look like through Monday morning?
  2. The FinCEN keyword FIN-2024-DEEPFAKEFRAUD must be in field 2 of the SAR. Why does FinCEN want this tag specifically? What does the SOC learn from the aggregate of these tagged SARs (i.e., what reporting does FinCEN publish back)?
  3. You preserve a suspect audio file with SHA-256 hash and native-container format. The defense attorney later argues the audio detector misclassified the audio. What additional artifacts would you want preserved at the time of acquisition to address this challenge?

Common mistakes

MistakeBetter approach
Transcoding audio/video for “easier analysis”Preserve native container; transcode a copy for analysis if needed
Manual SAR-keyword trackingEncode the FinCEN keyword logic in the SIEM-to-SAR pipeline so the keyword auto-populates
Treating IC3 RAT as a slow processGolden hour is 4 hours; have the RAT submission ready as part of incident response, not as a separate workflow
Skipping chain-of-custody for “small” incidentsEvery preserved artifact gets chain-of-custody. Investigations and litigation can resurface incidents months later.
Filing notifications sequentiallyNIS2 + DORA + state breach + FinCEN all run in parallel; the 3-hour MAS clock + 4-hour DORA clock + 24-hour NIS2 clock are concurrent

Closing Day 2

Day 2 has covered:

The architectural insight running through every module: artifact-level detection is necessary but insufficient. The workflow-gap detection — the absence of expected out-of-band verification — is the durable signal that survives as adversary tradecraft evolves.

Day 3 takes this insight to a different threat class: LLM-authored malware and prompt-injection campaigns against enterprise copilots. The detector’s stack evolves but the workflow-gap principle holds.