5.7 Incident Investigation with Security Copilot

Incident Investigation with Security Copilot

Introduction

Subsections 5.4 through 5.6 covered individual Copilot capabilities in each product. This subsection combines them into a complete investigation workflow — demonstrating how Copilot accelerates each phase of an incident investigation from initial alert through final report.

The worked example uses a BEC investigation scenario. The same methodology applies to any incident type — the prompts change, but the workflow pattern remains constant: summarise → investigate → correlate → assess → document.

The scenario

The SOC receives a high-severity incident in the Defender XDR queue: “Multi-stage incident involving j.morrison@northgateeng.com” with 7 correlated alerts spanning identity, email, and data protection.

Without Copilot, investigating a 7-alert incident manually takes 45-90 minutes: reading each alert, understanding the relationships, writing KQL queries, tracing the attack timeline, assessing data exposure, and drafting the incident report.

With Copilot, the same investigation takes 15-25 minutes — not because Copilot does the investigation, but because it accelerates the analyst’s work at each step.

Step 1: Incident summary (2 minutes)

Copilot prompt (embedded in Defender XDR): Copilot automatically generates the incident summary when you open the incident.

Copilot output (example): “This incident involves the compromise of j.morrison@northgateeng.com through an AiTM phishing attack. The user clicked a phishing link at 09:16 UTC, leading to a credential compromise at 09:22 UTC from IP 203.0.113.47 (Russia). Post-compromise activity includes: mailbox search queries for financial terms, reading 47 emails, creation of an inbox forwarding rule to attacker@proton.me, downloading 3 files from the Finance SharePoint site, and sending an email containing credit card data to an external Gmail address. 7 alerts are correlated across Defender for Office 365, Entra ID Protection, Defender XDR, and DLP.”

Analyst validation (1 minute): Spot-check three claims — the phishing email delivery time (check EmailEvents), the sign-in IP and country (check SigninLogs), and the forwarding rule creation (check CloudAppEvents). If all three match, the summary is reliable.

Value: This summary replaced 10-15 minutes of manual alert review with 2 minutes of reading and validation. The analyst starts the investigation already knowing the attack narrative, the affected entities, and the scope.

Step 2: Attack technique analysis (2 minutes)

Copilot prompt: “What are the MITRE ATT&CK techniques in this incident? For each technique, explain the attacker’s specific action and what evidence supports it.”

Copilot output (example): “T1566.002 (Phishing: Spearphishing Link) — the attacker sent a phishing email with a credential harvesting link. Evidence: EmailEvents shows email from hr-portal@contoso-updates.com delivered at 09:14 UTC.

T1557 (Adversary-in-the-Middle) — the attacker used an AiTM proxy to intercept MFA tokens. Evidence: SigninLogs shows MFA was satisfied at 09:22 UTC from an IP that is not the user’s device, indicating token relay.

T1114.002 (Email Collection: Remote Email Collection) — the attacker searched the mailbox for financial terms and read 47 emails. Evidence: CloudAppEvents shows MailItemsAccessed and SearchQueryInitiated events.

T1564.008 (Hide Artifacts: Email Rules) — the attacker created an inbox forwarding rule to exfiltrate ongoing email. Evidence: CloudAppEvents shows New-InboxRule creating a forward to attacker@proton.me.

T1048 (Exfiltration Over Alternative Protocol) — the attacker sent sensitive data via email to an external address. Evidence: DLP alert showing credit card data sent to Gmail.”

Analyst validation: Verify each technique mapping against the actual alert data. Copilot occasionally maps techniques incorrectly (assigning a technique that sounds similar but does not match the specific action). In this case, T1557 is debatable — AiTM is more accurately mapped to T1111 (Multi-Factor Authentication Interception) in newer MITRE versions. The analyst corrects the mapping.

Value: Technique analysis that would take 10-15 minutes (looking up each technique, mapping to evidence) takes 2 minutes with Copilot, including validation time.

Step 3: Deep investigation with KQL (5 minutes)

Copilot prompt 1: “Generate a KQL query that shows all MailItemsAccessed events for j.morrison@northgateeng.com between 09:00 and 12:00 UTC today, from IP 203.0.113.47, grouped by hour with a count of emails accessed.”

Copilot generates: A CloudAppEvents query filtering on MailItemsAccessed, the user account, the time window, and the attacker IP, with a summarize by bin(Timestamp, 1h).

Analyst validates and runs: Checks the table name (CloudAppEvents — correct), the filter on ActionType (MailItemsAccessed — correct), the user filter (correct), the IP filter (correct), the time window (correct). Runs the query. Results show 47 emails accessed between 09:22 and 11:28 from the attacker IP.

Copilot prompt 2: “Now generate a query that finds all inbox rules created by this user during the same time window. Include the rule parameters.”

Copilot generates: A query filtering CloudAppEvents for New-InboxRule and Set-InboxRule, extracting the rule parameters from RawEventData.

Analyst validates and runs: Confirms the query returns the forwarding rule created at 09:35, forwarding to attacker@proton.me. The analyst notes this for immediate remediation.

Copilot prompt 3: “Generate a query that shows all files downloaded from SharePoint by this user from the attacker IP during the compromise window.”

Copilot generates: An OfficeActivity query filtering for FileDownloaded, the user, the IP, and the time window.

Analyst validates and runs: Three files downloaded: Q4-Financial-Forecast.xlsx, Customer-Database-Export.csv, and Board-Strategy-2026.docx. All from the Finance Reports SharePoint site.

Value: Three investigation queries generated, validated, and run in 5 minutes. Manually writing these queries would take 15-20 minutes. The time saving is in the generation step — the validation step takes the same time regardless of how the query was created.

Step 4: Data exposure assessment (3 minutes)

Copilot prompt: “Based on the investigation so far, summarise the data exposure. What data was accessed, what was exfiltrated, and what are the regulatory notification implications?”

Copilot output (example): “Data exposure summary: The attacker accessed 47 emails (content unknown — check MailItemsAccessed for specific subjects if available). The attacker downloaded 3 files from the Finance Reports SharePoint site: a financial forecast, a customer database export, and a board strategy document. The attacker sent an email containing 15 credit card numbers to an external Gmail address (DLP alert — action was Audit, meaning the email was delivered). An inbox forwarding rule sent all incoming email to an external address from 09:35 to the time of containment. Regulatory implications: the credit card data exposure requires GDPR/UK GDPR notification assessment (72-hour deadline from awareness). The customer database may contain personal data requiring assessment.”

Analyst validation: Cross-check each claim against the raw data. Copilot correctly identified the data exposure vectors but the credit card count (15) and the forwarding rule timing (09:35) need verification against the DLP alert and audit log. Confirmed accurate.

Value: The exposure assessment narrative — which would take 10-15 minutes to write from the raw investigation data — was drafted in seconds. The analyst’s validation takes 3 minutes. Total: 3 minutes vs 15 minutes.

Step 5: Response and report (5 minutes)

Copilot prompt: “Draft an incident report for the CISO with these sections: Executive Summary (3 sentences), Attack Timeline (table format), Data Exposure Assessment, Response Actions Taken, Root Cause Analysis, and Recommendations. Include the GDPR notification deadline.”

Copilot generates: A complete incident report draft using the session context — all the information from steps 1-4 is incorporated. The executive summary captures the key facts. The timeline is a chronological table. The exposure assessment lists each data vector. The recommendations include inbox rule removal, DLP policy upgrade, conditional access hardening, and user security awareness.

Analyst edits: Corrects the MITRE mapping (T1557 → T1111), adds the specific response actions already taken (password reset at 11:30, sessions revoked, forwarding rule removed), adds the operational context (j.morrison is a Finance department analyst with access to sensitive financial data), and adds the GDPR notification timeline (“DPO notified at 12:00 UTC, 72-hour deadline expires March 21 12:00 UTC”).

Value: The report draft — which takes 30-60 minutes to write from scratch — was generated in 30 seconds. The editing and refinement takes 5 minutes. Total: 5 minutes vs 45 minutes.

Total time comparison

The validation checklist: what to verify at each step

After using Copilot for each investigation step, apply this validation checklist before proceeding:

For incident summaries: Check the alert count (does the summary match the actual number of alerts?). Check the entity names (are the user names, device names, and IP addresses correct?). Check the timeline (do the timestamps match the raw alert data?). Check the attack type classification (does the described attack match the alert evidence?).

For KQL queries: Check the table name (does the table exist in your schema?). Check the field names (do they exist in the table — use the schema explorer to verify). Check the filter values (country name vs code, exact string match vs partial match). Check the time window (does it match the investigation window?). Run the query and verify the result count is reasonable.

For MITRE ATT&CK mappings: Check each technique against the MITRE ATT&CK matrix. Verify the technique matches the specific observed activity, not just the general category. Copilot occasionally maps to a parent technique when a sub-technique is more accurate (T1566 Phishing vs T1566.002 Spearphishing Link).

For response recommendations: Check each recommendation against operational context. Is the recommended action feasible? Is it proportionate? Does it account for business impact? Is it consistent with your organisation’s incident response procedures?

For report drafts: Verify every factual claim traces to specific evidence. Remove any unsupported claims (hallucinated data volumes, fabricated details). Add operational context that Copilot cannot know. Ensure the report meets your organisation’s format and quality standards.

Common Copilot investigation errors and how to catch them

Through extensive use, specific error patterns emerge that you can watch for:

Entity confusion. When an incident involves multiple users or multiple IPs, Copilot may attribute an action to the wrong entity. If user A and user B are both involved, Copilot might state “User A downloaded 47 files” when it was actually User B. Validation: cross-check entity attributions against the raw alert data.

Temporal errors. Copilot may place events in the wrong order or miscalculate time gaps. “The attacker created the VM 30 minutes after the sign-in” may actually be 30 minutes before. Validation: verify the timestamps in the timeline against the raw data.

Severity inflation. Copilot tends to describe findings in their worst-case interpretation. “The attacker had full access to all company data” may be more accurately stated as “the attacker had access to the Finance SharePoint site.” Validation: check the actual scope of access against the user’s permissions and the evidence of what was accessed.

Missing context. Copilot summarises what is in the data but cannot identify what is missing. If an alert that should exist is absent (because the detection rule is not configured, or the data source is not connected), Copilot will not mention it. Validation: use your investigation experience to identify expected evidence that is not present in the summary.

The Copilot-analyst collaboration model

The most effective operational model is collaborative — Copilot handles data processing and content generation, the analyst handles evaluation and decision-making.

Copilot’s strengths (delegate these): Summarising large volumes of data. Generating structured KQL queries. Translating between natural language and technical output. Drafting reports from investigation data. Looking up threat intelligence for entities. Explaining unfamiliar alert types and attack techniques.

Analyst’s strengths (retain these): Evaluating whether findings are significant or benign. Making containment and remediation decisions. Providing organisational and operational context. Recognising novel attack patterns. Communicating with stakeholders. Taking response actions.

The collaboration is asymmetric: Copilot does the heavy lifting on data processing, the analyst does the lightweight but critical quality control and decision-making. Neither role can be eliminated — Copilot without analyst validation is unreliable, and analyst without Copilot is slower but equally effective.

When validation finds an error: the recovery workflow

Validation occasionally reveals Copilot errors. When it does, follow this recovery workflow:

Identify the error type. Is it a factual error (wrong entity name, wrong timestamp, hallucinated detail), a logic error (wrong KQL operator, incorrect join condition), or an interpretation error (wrong MITRE mapping, inappropriate response recommendation)?

Correct in the session. Tell Copilot about the error: “The incident summary states the user signed in from Russia, but the actual sign-in log shows the country as ‘RU’ which maps to Russian Federation — please use the correct country and update the summary.” Copilot corrects the output and the updated version is available in the session.

For KQL errors: Do not ask Copilot to self-validate — instead, describe the specific problem: “This query returns zero results. The field LocationDetails.countryOrRegion contains ISO country codes like ‘RU’, not full names like ‘Russia’. Fix the filter to use ‘RU’.” Copilot corrects the specific issue. This targeted correction is more reliable than asking “is this query correct?” (which Copilot typically answers “yes” regardless).

For hallucinations: Remove the hallucinated detail entirely from any report draft. Do not ask Copilot to “verify” the detail — it may confirm its own hallucination. Instead, check the raw data directly. If the data does not contain the claimed detail, delete it from the output. Note the hallucination in your validation log — tracking hallucination patterns helps you know where Copilot is most likely to generate unsupported claims.

Document the correction. If the corrected output is used in an official report, note that a correction was made: “Initial Copilot summary stated 2.3 GB exfiltrated; corrected to ‘data volume undetermined — storage diagnostic logging not configured for this account.’” This audit trail demonstrates rigorous validation.

Copilot finding what the analyst missed

Copilot’s comprehensive data access occasionally catches findings that the analyst missed during manual review. This is not a failure of the analyst — it is a demonstration of the collaboration model where AI and human each catch different things.

Worked example: During the BEC investigation, the analyst focused on the email compromise and data exfiltration. The incident report draft from Copilot included: “Additionally, the compromised account created an OAuth application registration at 10:03 UTC with the name ‘Azure Security Update’ and permissions for Mail.Read and Files.ReadWrite.All. This application represents a persistence mechanism — even after the password is reset and sessions are revoked, the attacker can use the OAuth application’s client credentials to access the mailbox and files without re-authenticating.”

The analyst had not checked for OAuth application registrations — it was not in their standard BEC investigation checklist. Copilot identified it because the CloudAppEvents data included an “Add application” event that Copilot’s incident summary captured.

Validation: The analyst checks CloudAppEvents for the OAuth app creation. Confirmed — an application was created with Mail.Read and Files.ReadWrite.All permissions at 10:03 UTC from the attacker IP. This is a critical finding: the OAuth application must be deleted immediately, or the attacker retains persistent access even after all other containment actions.

Lesson: Copilot processes all available data simultaneously. Analysts tend to follow a structured investigation path and may miss events outside that path. The combination of Copilot’s comprehensive data review and the analyst’s structured investigation expertise produces a more thorough investigation than either alone. This is the true value of the collaboration model — not just speed, but coverage.

Knowledge check