Incident Response, DFIR & Threat Intel with AI

AI can reconstruct a timeline from three misaligned log sources, decode an obfuscated script so you can read it, synthesize a week of threat reporting into one actor profile, and draft the incident report — turning hours of assembly into minutes. This module teaches the sourcing discipline that keeps that speed safe, because in IR a fluent, confidently-wrong timeline or a fabricated attribution does not just waste time — it becomes the official record.

The scenario — the timeline that named the wrong patient zero

The cost of the other timeline. Had she shipped the first version to the 09:00 bridge, the official incident record would have named an innocent colleague as patient zero, containment would have chased a VPN that was never the vector, and the actual web-app hole would have stayed open while everyone looked the other way.

The AI assembled a correct-looking narrative from real log lines and one wrong assumption — timezone — and narrative in an incident report does not get a second glance once leadership has read it. Time the AI saved on assembly: an hour of manual timestamp correlation. Time Ananya spent proving the ordering: twenty minutes, and it changed who the incident was about.

Reconstruct timelines — normalize first, prove the ordering

Here is the failure and the fix side by side, as the assistant produced them:

# FIRST PASS — wrong, because timezone was assumed
03:44 UTC  initial access  VPN session s.rao   <- src line stamped in LOCAL time, mislabeled UTC
03:51 UTC  lateral movement db-host
...

# CORRECTED — after proving each source's offset from an overlapping event
03:02 UTC  initial access  web-app exploit (Splunk)   <- the real patient zero
03:38 UTC  lateral movement db-host
03:49 UTC  benign VPN login s.rao (on-call responder)  <- exonerated

The single most dangerous input to an AI-reconstructed timeline is a timestamp whose timezone the model guessed. Ordering is the analysis in DFIR — who did what first is the whole question — and an ordering built on a mislabeled clock is a confident wrong answer, not an error you will notice.

The rule: never let the model assume a timezone — make it prove each source's offset from an event that appears in two sources, and require a verbatim quote per timeline entry so every ordering claim is checkable. Normalization is a fact you verify; ordering is an inference you test.

import anthropic
from pydantic import BaseModel

class TimelineEvent(BaseModel):
    utc_time: str
    source_tool: str
    raw_quote: str            # verbatim source line, so ordering is checkable
    offset_evidence: str      # how this source's TZ offset was established
    claim: str                # what happened, one sentence

class Timeline(BaseModel):
    events: list[TimelineEvent]
    unresolved_gaps: list[str]   # windows with NO source coverage
    assumptions_flagged: list[str]

client = anthropic.Anthropic()

response = client.messages.parse(
    model="claude-opus-4-8",
    max_tokens=4000,
    thinking={"type": "adaptive"},
    messages=[{
        "role": "user",
        "content": f"""Reconstruct an ordered incident timeline from these sources.

<edr>{edr_export}</edr>
<app_logs>{splunk_export}</app_logs>
<vpn>{vpn_export}</vpn>

Do NOT assume any source's timezone. For each source, establish its UTC
offset from an event visible in two sources, and record that in
offset_evidence. Quote every event verbatim. Flag windows with no coverage
as gaps — do NOT infer events to fill them.""",
    }],
    output_format=Timeline,
)

timeline = response.parsed_output

The unresolved_gaps field is as important as the events. A model that smooths over a coverage gap with a plausible inferred event is fabricating the incident; one that flags "no source covers 03:10–03:30" tells you exactly where to pull more artifacts.

Root-cause hypotheses — ranked, and each one falsifiable

Timelines tell you what happened; root-cause analysis asks why, and this is where fluency is most seductive. Ask for a single root cause and the model gives you one confident story. Ask correctly and you get a ranked set of hypotheses, each with the test that would kill it:

Given this timeline and these artifacts, propose the top 3 root-cause
hypotheses for initial access, ranked by likelihood. For EACH, give me: the
evidence that supports it (quoted), and ONE concrete check — a query, an
artifact to pull, a log to examine — that would DISPROVE it if false. Do not
commit to one cause. I will run the checks.

This is the same trust-calibration move as M1, applied to causation. The model that must hand you the disconfirming check for each hypothesis cannot anchor you on a single wrong story — it has to expose the test that would break it. Ananya's whole correction came from running the check that disproved "VPN was patient zero."

Analyze artifacts safely — decode to read, never to run

DFIR means reading hostile things: an obfuscated PowerShell one-liner, a Base64 blob in a registry run-key, a suspicious macro. AI is excellent at deobfuscation, and the guardrail is a bright, unmovable line — you decode and explain; you never execute, fetch, or construct anything runnable.

Here is an obfuscated command recovered from an endpoint. DECODE it layer by
layer and EXPLAIN what each stage does, so I can understand the attacker's
intent. Rules: this is READ-ONLY analysis. Do NOT execute anything. Do NOT
construct a working version. If it references a URL, show me the URL as text
— do NOT fetch it. If it downloads a payload, describe the behavior; do not
retrieve the payload. Output: decoded plaintext + a plain-English explanation.

Peeling three layers of Base64-and-XOR off a downloader to reveal "it fetches a second stage from hxxp://... and adds a run-key" is exactly the analysis IR needs, and it is completely safe — you are reading, not running. A typical layered explanation reads like this, and every line of it is understanding, not execution:

Layer 1: Base64 -> a PowerShell command with -EncodedCommand
Layer 2: decoded -> gzip-compressed bytes
Layer 3: decompressed -> a downloader that:
  - reaches out to hxxp://192[.]0[.]2[.]10/s[.]bin   (DEFANGED — do not fetch)
  - writes it to %APPDATA%\svc.exe
  - registers a Run key for persistence
Intent: stage-2 retrieval + persistence. IOCs: the URL, the filename, the run-key.

The line you never cross, in the prompt or in your own hands, is turning decoded content into action: executing it, curling the URL, pasting it into a live shell. That belongs in an isolated, instrumented sandbox under separate controls — never in your analysis window, and never as something you ask the model to do. The output of safe analysis is understanding plus defanged IOCs that feed straight back into M2's detection work — the run-key path, the staging filename, the C2 URL all become detection content — closing the loop from artifact to rule without a single byte of the sample ever running where it should not.

Defang recovered indicators (hxxp, 192[.]0[.]2[.]5) in everything you write, so a decoded URL in a report cannot become an accidental click for the next reader. The model analyzes the sample; it must never become the thing that detonates it.

Threat intel — synthesize widely, source every claim, guard attribution

Two CTI tasks pay off daily, and both live or die on sourcing.

Report synthesis and actor tracking. Feed a week of vendor reports, blog posts, and internal notes and ask for a consolidated actor profile or campaign summary — the TTPs, the infrastructure, the targeting, the trend. The output is a fast, readable brief, and the trap is attribution. An LLM synthesizing loosely will state "this is APT-XX" with unearned confidence, blending one source's tentative hypothesis with another's confirmed finding into a single flat assertion. Attribution is the highest-stakes claim in CTI and the easiest for a model to launder.

Synthesize these sources into an actor/campaign profile. For every claim,
cite which source it came from. Separate CONFIRMED findings from a single
source's HYPOTHESIS. For attribution specifically: state the confidence each
source assigns and do NOT upgrade a "possible" or "assessed" link to a
definite one. Contradictions between sources must be surfaced, not resolved.

The instruction to preserve each source's confidence level — and never upgrade a "possible" to a "confirmed" — is what keeps synthesis honest. Contradictions between sources are signal, not noise to be smoothed; a brief that hides them is more dangerous than no brief.

Phishing verdicts with rationale. For a reported phishing email or URL, the model classifies and explains: header anomalies, sender-domain mismatch, lure pattern, defanged URL analysis. The prompt shape keeps it grounded and safe:

Analyze this reported email for phishing. Base your verdict ONLY on the
headers and body provided. State each signal you find and quote the header
line it comes from — do NOT assert SPF/DKIM/DMARC results you cannot see in
the provided headers. Defang every URL (hxxp, [.]). Do NOT fetch any URL or
attachment. Output: verdict, per-signal rationale with quotes, confidence.

This is genuinely useful triage, and the discipline is that the verdict is a hypothesis and the rationale is what you check. A "malicious" call with a fabricated reason — "SPF failed" when the provided headers show it passed — is worse than no call, because it teaches the reporter to trust a wrong signal and trains your team to distrust the tool. The load-bearing instruction is "do not assert authentication results you cannot see": an LLM will confidently narrate SPF, DKIM, and DMARC outcomes from a lure it finds suspicious, whether or not the headers actually support them. Ground the verdict in the quoted headers, and the phishing assistant becomes a fast, checkable first pass instead of a confident-sounding guess.

Draft reports and briefings — the byline is yours

The incident report, the exec brief, the blameless post-incident review, the leadership threat briefing — all four are LLM-draftable from artifacts that already exist: the timeline, the actions log, the findings. The draft kills the blank page that keeps reports thin and late, and the rule that keeps them true is the byline rule.

Each document has a different audience and a different failure mode, and the drafting prompt should name both:

• The exec briefneeds certainty stated honestly, "confirmed" versus "assessed" versus "under investigation", because leadership reads confidence as a number to act on, and an LLM that flattens a tentative finding into a flat assertion drives a wrong decision at the top.
• The leadership threat briefingneeds the "so what" for the business, not the packet-level detail.
• The post-incident reviewneeds chronology and contributing causes without individual fault.

The responder who owns the incident owns every claim in the report. The model drafts fluently and, when wrong, specifically fluently-wrong — a post-incident review that misstates the detection gap becomes organizational false memory in a professional tone, and it becomes that false memory precisely because it is well-written. For the blameless review, instruct the model explicitly to describe systems and process, never individual fault — Ananya's report must never read as "s.rao's VPN caused this," which is exactly the story the first AI timeline would have written, and exactly the wrong that the byline exists to catch. You edit, you verify each claim against the artifact it came from, and you sign.

The reporting clock and the compliance line

DFIR in India runs against two statutory timers, and the timeline you reconstruct is the evidence for both. CERT-In requires reporting certain incidents within 6 hours of detection; where personal data is breached, the DPDP regime adds the Data Protection Board's 72-hour obligation. Reconcile them deliberately — the 6-hour CERT-In clock is the tighter one and starts at detection, so an accurate, defensible timeline is not just investigation hygiene, it is what makes a truthful, on-time report possible.

The services constraint holds throughout, and it is sharpest in IR because incident artifacts are the most sensitive data a SOC ever handles — raw logs, memory captures, and file contents carry client PII, credentials, and confidential detail that cannot be pasted into public AI tools. Use client-approved or local endpoints for anything tenant-specific, redact and minimize before prompting, and keep the raw evidence inside the client-approved boundary. A redacted timeline is portable; the raw logs behind it are not.

The chain of custody adds a second dimension. Evidence handling in an incident that may lead to legal action means you must be able to show where every artifact went and what touched it — and "pasted into a public LLM" is exactly the kind of uncontrolled exposure that can taint evidence and breach a client contract at the same time. Running analysis on local models over a controlled copy keeps the AI inside the boundary the investigation already requires, which is why the local-model path is not a compromise in DFIR but the correct default.

Where this lands in your week

• This weektake your next timeline reconstruction and refuse to let the model assume a single timezone: make it prove each source's offset from an overlapping event, quote every entry, and flag the coverage gaps instead of filling them. The moment it changes your ordering, as it changed Ananya's, is the moment you understand why sourcing discipline is the job and not the paperwork.
• Within a monthbuild the ranked-hypothesis-with-disconfirming-check habit into your RCA, and set up a CTI synthesis flow that preserves per-source confidence and defangs every indicator.
• Ongoingthe habit that compounds is Ananya's twenty minutes: every AI-assembled timeline, verdict, and report is a hypothesis you source before it becomes the record, because in IR the fluent wrong answer does not just cost you time, it names the wrong patient zero in the official history.

This module anchors LAB-05 (incident timeline reconstruction): reconstruct an ordered narrative from three misaligned log sources for a scripted intrusion, with per-event source citations and flagged gaps. The artifact — a timeline document where every event quotes its source, every source's timezone offset is proven, and the coverage gaps are marked rather than smoothed over — is the strongest interview evidence this module produces: anyone can say "I use AI for IR"; you can show the reconstruction where the AI's confident patient-zero was wrong and your sourcing discipline caught it before it reached the bridge.

Your playbooks & retrieval check

Check yourself: An AI reconstructs a clean incident timeline that names a specific user as patient zero, every event quoted to a real log line. What single assumption most often makes that ordering wrong, and how do you force the model to prove it?

Companion playbooks — take these into your week alongside LAB-05: pb-10 (Reconstruct an Incident Timeline from Misaligned Log Sources), pb-13 (Safely Deobfuscate and Explain a Suspicious Script), and pb-11 (Draft an Incident Report and Executive Brief from Structured Facts).