Writing

Intrusion Analysis: From Alert to Defensible Findings

By Brandon Eckert

An intrusion analysis should make a decision easier to defend. Explain what happened, which systems and data may be affected, what supports that conclusion, and what still needs to be checked. A convincing narrative is useful only when another analyst can follow it back to the evidence.

This guide pairs a repeatable investigation method with a comprehensive Excel workbook. The companion Cyber Kill Chain analysis examines the same incident through adversary stages and defensive opportunities.

Simulation notice: Case SIM-2026-001 describes Example Services, a fictional company. All people, systems, activity, contextual statements, and conclusions are invented. This is educational material, not an assessment of a real organization or a description of my employer. The example is complete as an analytical record at October 14, 2026, 16:00 UTC; the fictional incident remains open.

Download the investigation workbooks

Each file has 15 worksheets, internal navigation, filterable tables, dropdown lists, an action summary chart, and print layouts. The blank template keeps instructions and formulas while leaving incident facts empty. Use a separate private copy for a real case, with evidence stored in your organization’s approved repository.

1. Define the question and the authority to act

Start with a question that can be answered: was an account used without authorization, what did that access reach, and which response decisions cannot wait? Record the case owner, incident commander, business owner, technical responders, approval authority, and communication cadence in Case Overview. Describe the affected service, dependencies, review window, exclusions, and initial severity rationale.

Severity, business impact, confidence, and action priority answer different questions. A plausible path to sensitive reports may justify urgent containment while the amount of external exposure remains uncertain. Avoid converting uncertainty into a made-up numerical score or treating an action deadline as a universal response standard.

NIST SP 800-61 Rev. 3, published in April 2025, places incident response within ongoing cybersecurity risk management. Use the investigation to support detection, response, and recovery decisions as evidence develops. The steps here are an iterative working method, not a requirement to finish analysis before containment.

In the example, Alex’s account normally permits VPN access, RDP to APP-01, and reads from a Finance reports library. There are no blanket domain administrator rights. The simulated account-holder denial in CTX-001, linked identity and host activity, and an unapproved task support a high illustrative severity. Neither an unfamiliar address nor use of PowerShell establishes malicious intent on its own.

2. Preserve evidence with its limits attached

Use Evidence Register to record a stable evidence ID, source, collection method and time, coverage window, location, collector, access restrictions, integrity hash, and known gaps. Use Custody Log for actual collection and transfers: who handled what, when, why, and how integrity was checked. Preserve originals and conduct analysis on working copies.

Prioritize evidence by volatility, retention, relevance, and collection impact. Memory and active sessions may disappear; a provider’s short retention window can expire while endpoint work proceeds. Document the collection commands or export parameters, tool versions, query scope, and any changes caused by collection. A screenshot of an alert is useful context but rarely contains the records needed to reconstruct the activity.

Coordinate preservation with containment. If leaving a session active creates unacceptable harm, record the decision, approver, reason, and evidence that could not be captured before restriction. Do not erase the trade-off from the final account. NIST SP 800-86 provides older forensic process guidance; its collection and examination principles remain useful, while its product examples should be read in their 2006 context.

The example contains six normalized JSON log sources and four contextual records in the manifest. These are deliberately simplified educational records, not native exports from any named product. Their SHA-256 values verify that downloaded fixture bytes match the workbooks. A matching hash does not establish the authenticity, completeness, or legal sufficiency of real evidence.

3. Reconstruct time and join activity carefully

The Timeline preserves original timestamps, normalized UTC event times, ingestion times, signed clock corrections, correction basis, entity/session references, observations, and interpretations. Sort on normalized event time while retaining the original value. Ingestion delay and clock error are different problems; apparent ordering can change when either is understood.

For EVT-024, the source reports 2026-10-13T05:12:00-04:00. That is 09:12 UTC before correction. The documented correction is −120 seconds, yielding 09:10 UTC. CTX-003 provides the simulated clock-check basis, and EVT-031 records later resynchronization. Keep the uncertainty visible rather than silently replacing the source time. Joint event logging guidance emphasizes consistent timestamps, useful correlation fields, retention, and protected log storage.

The suspicious sequence is linked through several keys:

EVT-017: identity session IC-77 accepted
  -> EVT-018: assertion ASSERT-77 issued
  -> EVT-019: VPN V-77 assigns 10.20.0.77
  -> EVT-020: RDP flow from that assignment to APP-01
  -> EVT-021: destination logon L-712

Validate the account, assertion, tunnel, address-assignment interval, destination, and logon context together. A reused IP address is not a permanent device identifier, and an account name does not identify the human operating it. EVT-032 separately links cloud session C-88 with IC-77; do not assume every cloud request traversed the VPN.

Preserve relevant ordinary activity before the alert. It provides a comparison and can expose false leads. The detector alert at EVT-037 is a starting point for review, not independent proof of every event it summarizes.

4. Test explanations and seek contradictions

Write a claim in Hypotheses, list supporting and contradictory records, state confidence with a reason, and identify the next observation that could distinguish alternatives. Keep a dated assessment history when your conclusion changes. Repeating one alert in several dashboards does not create several independent sources.

Question Assessment and next check
Is Alex’s identity being used without authorization? Linked identity, VPN, logon, and task activity plus CTX-001 support the claim with high confidence. Review the original authentication chain and Alex’s workstation.
Is ReportCache approved maintenance? CTX-002 authorizes a separate PatchWindow change. The identities, task actions, and context differ; EVT-024 contradicts the maintenance explanation. Preserve both task definitions and the change record.
Was the password stolen, or was an existing session reused? The records support access but do not distinguish acquisition mechanisms. Obtain provider authentication context and relevant browser/device artifacts.
Did the collected data reach an external recipient? Staging, cloud operations, and TLS traffic raise the question; content and recipient evidence are incomplete. Recover missing egress records and cloud recipient context.

The workbook’s confidence rubric uses Low, Moderate, and High for a precisely scoped claim; Not assessed means no analytical confidence has been assigned. High confidence in unauthorized access does not imply high confidence in the actor’s identity or the amount of data stolen. Unknown is an answer about missing knowledge, not a lower-severity incident state.

5. Expand scope without turning gaps into clean results

Pivot from the initial account and host to related sessions, accessible services, alternate accounts, persistence locations, and relevant data. Record how the pivot was made and which source/window was searched. Capture query logic and exclusions so another analyst can reproduce the boundary of the review.

Entities and Scope distinguishes four states: confirmed compromise, suspected impact, reviewed without findings, and not yet reviewed. In this example, the Alex identity and APP-01 are confirmed within the synthetic case; the Finance library has suspected impact. The operations account and backup account have bounded reviews without findings. Alex’s assigned workstation, WS-014, is not yet reviewed. It must not acquire a clean status because its endpoint records are absent.

Put missing material in Collection Gaps with an owner, priority, next step, and effect on the conclusions. The network sensor gap from 09:30 to 10:15 UTC on October 13 limits transfer analysis. Missing memory and workstation artifacts limit persistence and acquisition findings. If retention makes a source unrecoverable, record that result and preserve the resulting limitation.

6. Describe behavior with reasoned ATT&CK mappings

Use ATT&CK Analysis to link a technique to an observed procedure, evidence, mapping rationale, confidence, assessment date, and limits. The example uses these mappings, reviewed October 17, 2026:

These mappings can overlap and do not require a one-to-one relationship with Kill Chain stages. They do not prove a particular malware family, exploited CVE, MFA bypass, actor, or detection capability. None of those mechanisms is established by this evidence pack.

7. Separate access, collection, staging, and transfer

Treat each as a different finding. Permission to read a library does not prove every object was read. A listing is not a download. A local archive is not proof of an external transfer, and service-recorded download bytes do not identify a final receiving person.

The example has several distinct measurements:

Observation Meaning and limits
EVT-026 Local report access references 31 paths. This is not the same population as the cloud objects.
EVT-028 A local reports.zip artifact is 4,401,392 bytes. No transfer or matching cloud content is proved.
EVT-034–EVT-036 Three distinct cloud objects have recorded download operations totaling 4,407,296 bytes. Receiving-device completion, recipient, and total exposure remain unknown.
EVT-030 A TLS connection records 86,000 bytes toward the external endpoint. Process attribution and decrypted content are absent.
EVT-038 The VPN records aggregate traffic counters. Those counters include protocol and other traffic; they are not stolen-file totals.

Do not add these numbers together. They measure different objects and layers and may overlap. The library listing at EVT-033 references 31 objects but supplies no evidence that all 31 were downloaded. Keep confirmed operations, suspected exposure, and unresolved external receipt separate in Impact and Recovery.

8. Make response and recovery testable

Decisions and Actions separates the decision to act from its implementation. Record the trigger, rationale, approver, owner, deadline, dependencies, expected effect, status, and validation criteria. Preserve the decision even when an action is later superseded.

In the example, EVT-041 records identity restriction and grant revocation. Subsequent refresh and cloud-request denials at EVT-042 and EVT-043 validate sampled paths. Ending VPN V-77 at EVT-040 did not itself revoke the cloud session. EVT-044 records host isolation and task disablement; EVT-045 samples a denied RDP path. These observations support bounded containment, not a claim that every session and persistence mechanism has been eliminated.

Define recovery criteria before declaring success: approved restoration state, integrity checks, credential/session remediation, persistence review, monitoring coverage and duration, business acceptance, and residual risk owner. EVT-048 shows a service-health response in an isolated recovery context. It does not satisfy all recovery criteria.

The snapshot retains four open actions, including one overdue target. Closure requires a named decision-maker, resolved or explicitly accepted gaps, documented recovery validation, and a way to reopen the incident if new sessions, additional persistence, wider data access, or contradictory evidence appear.

9. Write findings another analyst can challenge

A concise handoff should state the question, reviewed scope and sources, supported sequence, confirmed and suspected impact, confidence, containment validation, remaining uncertainty, and the next owned decisions. Attach stable references rather than embedding unrestricted evidence in a public workbook.

For this case: unauthorized use of the Alex identity and APP-01 activity is supported with high confidence. An unapproved task registers and executes. Three cloud objects have recorded download operations. Initial credential/session acquisition, actor attribution, command and control, final recipient, and total exposure remain unresolved. Containment has sampled validation; recovery and closure remain open.

Use Lessons and Detections to turn findings into work: correlation across identity and VPN assignment, authorized-change context for task detections, clock-quality checks, egress retention, and tests for session revocation. Give each proposal telemetry prerequisites, benign comparison activity, an owner, and an observed validation result when executed. A proposed rule remains untested until that work occurs.

Use and extend the workbook

Begin on Start Here, enter the case ID and a real UTC analysis date in Case Overview, then register evidence before interpreting events. The date is an explicit snapshot; overdue counts do not change with the wall clock. Pale amber cells identify workflow inputs, and text labels remain meaningful without color. Read References and Lists for field definitions and the confidence rubric.

Add records inside a table or press Tab in its final cell. Check that filters, formulas, validation, and formatting extend. If your spreadsheet application does not autofill them, copy the preceding table row, replace its inputs, and verify the summary. Enter due and analysis dates as actual spreadsheet dates. A missing analysis date displays a prerequisite message for populated actions; missing action type/state counts expose incomplete records.

The files use ordinary formulas and no macros or external workbook connections. Headless LibreOffice recalculation was checked on edited copies; Microsoft Excel native open/save remains unverified. Print selected sheets or column groups rather than assuming a comprehensive working record should fit on a single page. Preview pagination after adding long notes.

Download the shared synthetic evidence

Save these eight files together in an evidence folder beside the workbooks. Read the README first. In manifest.json, look up an event ID to find its evidence ID, filename, and JSON pointer such as /events/0. The four CTX- records are invented interview/change/clock/authority context in the manifest, not additional log sources. The workbooks contain their references and the six source-file hashes.

Continue with the Cyber Kill Chain analysis and companion workbook to examine stage visibility, competing mappings, and places to interrupt the observed activity.

← All writing