12.10 Scope Assessment: Who Else Was Hit?

4-6 hours · Module 12

Scope Assessment: Who Else Was Hit?

Containment and eradication addressed the known compromised accounts. Scope assessment determines the full blast radius of the campaign — every user who was targeted, every account that may be compromised, and every data store that may have been accessed.

Comprehensive scope query

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Complete campaign scope — all users who interacted with phishing infrastructure
let PhishingDomains = dynamic(["secure-portal-verify.com", "microsoftonline-auth.com", "sharepoint-secure-docs.com"]);
let AttackerIPs = dynamic(["203.0.113.47", "203.0.113.52", "203.0.113.89"]);
// Users who received phishing emails
let Targeted = EmailEvents
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where SenderFromDomain in (PhishingDomains)
    or SenderFromAddress in (
        "j.morrison@northgateeng.com", "s.chen@northgateeng.com", "a.patel@northgateeng.com")
| distinct RecipientEmailAddress;
// Users who clicked
let Clicked = UrlClickEvents
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where Url has_any (PhishingDomains)
| where ActionType == "ClickAllowed"
| distinct AccountUpn;
// Users with sign-ins from attacker IPs
let Compromised = SigninLogs
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where IPAddress in (AttackerIPs)
| where ResultType == "0"
| distinct UserPrincipalName;
// Combine into scope summary
Targeted | extend Status = "Targeted"
| union (Clicked | project RecipientEmailAddress = AccountUpn, Status = "Clicked")
| union (Compromised | project RecipientEmailAddress = UserPrincipalName, Status = "Compromised")
| summarize Statuses = make_set(Status) by RecipientEmailAddress
| extend MaxSeverity = case(
    "Compromised" in (Statuses), "COMPROMISED",
    "Clicked" in (Statuses), "CLICKED — investigate",
    "TARGETED — no interaction")
| order by MaxSeverity asc

Output: A table showing every user’s exposure level. Users marked COMPROMISED need the full containment and eradication workflow (11.7-11.8) if not already completed. Users marked CLICKED need sign-in log investigation (11.5) to determine if they entered credentials. Users marked TARGETED need awareness notification.

Data exposure assessment

For each compromised account, quantify the data exposure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// Data exposure — emails accessed by the attacker per user
CloudAppEvents
| where TimeGenerated > datetime(2026-02-27T08:00:00Z)
| where ActionType == "MailItemsAccessed"
| extend ClientIP = tostring(parse_json(RawEventData).ClientIPAddress)
| where ClientIP in ("203.0.113.47", "203.0.113.52", "203.0.113.89")
| summarize
    EmailsAccessed = count(),
    FirstAccess = min(TimeGenerated),
    LastAccess = max(TimeGenerated),
    DurationHours = datetime_diff('hour', max(TimeGenerated), min(TimeGenerated))
    by AccountDisplayName
| order by EmailsAccessed desc

Compliance mapping: NIST CSF RS.AN-2 (The impact of the incident is understood). The email count and user roles determine whether data breach notification is required. If the compromised accounts had access to PII, financial data, or health information, the organisation may have regulatory notification obligations (UK GDPR: 72-hour notification to ICO if personal data breach likely risks individuals’ rights).

Subsection artifact: The scope assessment query and data exposure query. These feed directly into the IR report (11.11) scope section.

Knowledge check

Data breach notification assessment

The scope assessment determines whether data breach notification is required under applicable regulations.

UK GDPR (Data Protection Act 2018): Notification to the ICO is required within 72 hours if the breach is likely to result in a risk to the rights and freedoms of individuals. Assess: did the attacker access emails containing personal data (employee PII, customer data, health information, financial data)? If yes: the 72-hour clock starts when you confirmed the breach — not when you completed the investigation.

Assessment framework:

1
2
3
4
5
6
7
8
9
// Estimate personal data exposure per compromised user
// Check: what types of email does this user typically handle?
EmailEvents
| where TimeGenerated > ago(90d)
| where RecipientEmailAddress == "j.morrison@northgateeng.com"
| where Subject has_any ("payroll", "salary", "bank details", "passport",
    "NI number", "national insurance", "medical", "health",
    "personal", "confidential", "HR")
| summarize PotentialPIIEmails = count()

If the compromised user (a Finance Manager in this case) regularly receives emails containing financial PII, and the attacker accessed 340 emails from that mailbox: the probability that personal data was exposed is high. This triggers the 72-hour notification requirement.

Document the notification decision: “Assessment: attacker accessed 340 emails from j.morrison (Finance Manager) over 3 hours. j.morrison regularly handles payroll and vendor payment data containing employee bank details. Risk assessment: likely risk to individuals’ rights and freedoms. Recommendation: notify ICO within 72 hours. Legal counsel consulted at [time].”

Try it yourself

For the Northgate Engineering scenario with 3 compromised users (j.morrison — Finance Manager, s.chen — IT Administrator, a.patel — Accounts Payable Clerk): assess each user's likely email content based on their role. Which users' mailbox access is most likely to trigger data breach notification? Draft a one-paragraph notification assessment for each user. This exercise builds the skill of translating technical findings into regulatory compliance decisions.

What you should produce

j.morrison (Finance Manager): high probability of personal data exposure — payroll, vendor bank details. Notification likely required. s.chen (IT Administrator): moderate probability — may contain system credentials, employee device information. Assess further. a.patel (Accounts Payable): high probability — vendor financial data, potentially employee expense claims. Notification likely required.

Check your understanding

1. The scope query shows 12 users with status "CLICKED" but only 3 with status "COMPROMISED." Should you investigate the other 9 clickers?

Yes. Every clicker must be investigated. "Clicked but not compromised" may mean: the user clicked but did not enter credentials (closed the AiTM page), the user entered credentials but the token capture failed, or the sign-in from the attacker IP used a different IP not in your AttackerIPs list. Run the sign-in log investigation (11.5) for each clicker. If no suspicious sign-in is found, classify as "Clicked — no compromise confirmed" and document.

No — they clicked but were not compromised

Only investigate if they report a problem

Reset all 12 passwords as a precaution

Every clicker must be investigated individually. "Not compromised" based on known attacker IPs does not guarantee no compromise — the attacker may have used additional IPs. Document each investigation outcome.

← 12.9 Campaign Tracking Across Waves 12.11 CISO Report →