A gap in logs that should be continuous is an IoC, not a clean bill of health.
The natural human reaction to missing log data is "there's nothing there to analyze." This is exactly backwards. In a well-configured environment, logs are continuous. A server that runs 24/7 generates authentication events, system events, and network events all day. A gap — particularly during a window when other evidence suggests attacker activity — means someone deleted that evidence.
The exam tests this intuition directly with distractors that frame missing logs as inconclusive. They are not inconclusive — they are forensically positive evidence that an attacker with sufficient privileges removed log data to cover their tracks. The deletion act itself is often captured in the SIEM (e.g., Windows Event ID 1102: "The audit log was cleared").
Impossible travel is about sequential logins with an impossible time gap. Concurrent sessions are about simultaneous active logins.
The exam uses these interchangeably in distractors. They are different observations:
- Impossible travel: User logs in from Location A at T1. User logs in from Location B at T2. The distance between A and B divided by (T2 − T1) exceeds physical transportation velocity. One of these sequential logins must belong to an attacker.
- Concurrent sessions: User has two or more active sessions at the same time from different locations. No time-gap calculation is performed — both sessions are active simultaneously.
The key differentiator: impossible travel computes velocity between sequential logins. Concurrent sessions observe simultaneous activity. Impossible travel has a clear mathematical threshold (can the distance be covered in the time?). Concurrent sessions require business context to evaluate (are both sessions explainable by the user's known devices?).
The bandwidth spike at 3 AM may be the first detection event even when the attacker has been present for months.
Exam scenarios often present resource consumption IoCs and ask what the analyst should conclude about the timing of the breach. The distractor answer is that the breach "just started" based on when the bandwidth spike was detected. This is almost always wrong.
The correct understanding: attackers establish access, move laterally, identify target data, and only then exfiltrate. The exfiltration event — which produces the resource consumption IoC — comes at the end of a multi-phase attack chain that may have started weeks or months earlier. The resource consumption spike is the first visible IoC, not the beginning of the breach.
This has direct implications for the forensic investigation: when a bandwidth spike is detected, the timeline must be reconstructed backward from that event to find the initial access point (often a phishing email, a compromised credential, or an unpatched vulnerability that was exploited long before any visible activity).
An attacker deliberately triggering a lockout is not a failed brute force attempt — it is phase one of a social engineering attack.
The exam presents account lockouts as straightforward: too many failed attempts → account locked → attack failed. This framing misses the attack chain where the lockout is the goal, not the failure condition.
The scenario: an attacker who cannot crack the target's password instead deliberately submits enough failed login attempts to lock the account. They then impersonate the user to the help desk and request a password reset. If the help desk resets the password based on basic identity verification (name, employee ID, date of birth — all obtainable from public sources), the attacker now has valid credentials for the account without ever cracking the original password.
This is why strong password reset procedures are treated as a security control, not just a customer service process. The lockout IoC should trigger investigation of help desk contacts for that account, not just an automatic unlock.
Performance Task
You are the lead incident responder for a regional insurance company. The following three events are reported to you within a 48-hour window. For each event, identify the IoC category, explain the significance, and provide the priority response actions.
The IT service desk receives a call at 10:22 AM from someone claiming to be the company's CFO. The caller states their email account has been locked and they need an immediate password reset because they have an important investor call in 20 minutes. The help desk technician confirms the CFO's name, employee ID, and home zip code match records on file, and resets the password over the phone. At 10:35 AM, the CFO walks into the IT office in person to report that her email account was locked this morning and asks for help unlocking it.
Questions: What IoC does this represent? What attack chain has unfolded? What immediate actions are required? What process failure enabled this attack?
IoC: Account lockout used as phase one of a social engineering attack chain targeting credential reset. The attacker intentionally triggered the CFO's account lockout, then called the help desk impersonating the CFO before the real CFO could report the lockout.
Attack chain: (1) Attacker submits N+1 failed login attempts against the CFO's account → account locks. (2) Attacker calls help desk immediately, impersonating CFO, uses urgency framing ("investor call in 20 minutes") to pressure the technician into bypassing normal procedures. (3) Help desk resets the password using identity information (name, employee ID, zip code) that is obtainable through OSINT and social engineering. (4) Attacker logs in with the new password and has full access to the CFO's email. (5) Real CFO arrives 13 minutes after the reset.
Immediate actions: (1) Lock the CFO's email account immediately — the attacker is likely in the account right now. (2) Preserve all login activity since the reset (10:22 AM) — what was accessed, what was read, what was forwarded or deleted. (3) Check email forwarding rules — attackers commonly add a forwarding rule to exfiltrate email silently going forward, even after the account is locked again. (4) Check for sent emails or authorized wire transfer instructions sent from the account in the last 13 minutes. (5) Force a full credential reset through in-person verification with the CFO now standing in the office.
Process failure: The help desk reset a password based solely on knowledge-based authentication (name + employee ID + zip code) provided over the phone by an unverified caller. This information is findable through LinkedIn, public records, and social engineering. The required control: never reset credentials based on self-reported identity provided by the caller. Require manager approval, out-of-band callback to a pre-registered number, or in-person ID verification. Urgency framing ("I have a meeting in 20 minutes") is a social engineering technique designed to bypass security procedures — it should trigger more scrutiny, not less.
The SIEM generates an alert at 3:17 AM: the claims processing database server (CLAIMS-DB-02) has transferred 28 GB of data outbound to IP address 91.217.190.44 (geolocation: Romania) via HTTPS (port 443). The server's normal nightly outbound traffic averages 180 MB. Six hours later, a review of CLAIMS-DB-02's local authentication logs reveals they contain no entries between 2:55 AM and 3:45 AM — a 50-minute window. However, the SIEM shows 47 authentication events during that same window, including a login by the service account "svc-claimsapp" from an internal IP (10.14.5.88) not associated with any known claims application server.
Questions: What two IoC categories are present? What does the evidence show about the attacker's actions? Why is the SIEM critical in this investigation?
Two IoC categories present:
(1) Resource consumption: The 28 GB outbound transfer at 3:17 AM to a Romanian IP via HTTPS is active data exfiltration. CLAIMS-DB-02 holds customer claims records — 28 GB represents a substantial portion of that database. The 155× spike above normal traffic (180 MB vs. 28 GB) leaves no ambiguity about the nature of the event.
(2) Missing logs: The 50-minute gap in CLAIMS-DB-02's local authentication log (2:55 AM–3:45 AM) is deliberate log deletion. The attacker cleared the Windows Security Event Log to remove evidence of the "svc-claimsapp" login from 10.14.5.88 and the authentication activity during the exfiltration window. The gap does not mean nothing happened — it means the attacker tried to make it look that way.
What the evidence shows: The attacker logged into CLAIMS-DB-02 using the "svc-claimsapp" service account from an internal host (10.14.5.88) at approximately 2:55 AM. They queried or exported the claims database, then initiated an outbound HTTPS transfer of 28 GB to 91.217.190.44. At some point during or after the exfiltration, they cleared the Windows Event Log on CLAIMS-DB-02 to remove their login record. The exfiltration completed by approximately 3:45 AM based on the log gap endpoint. The attacker likely then terminated their session.
Why the SIEM is critical: The SIEM preserved the 47 authentication events that the attacker deleted from the local server. Without the SIEM's real-time log forwarding, the investigation would have a 50-minute gap with no evidence of how the transfer occurred or what credential was used. The SIEM shows the "svc-claimsapp" login from 10.14.5.88 — this is now a pivot point for the investigation: how was svc-claimsapp's credential obtained? Where is 10.14.5.88 (it's not a known claims server — it may be a compromised internal host used as a lateral movement stepping stone)? The investigation now extends to tracing how the service account credential was obtained and what host the attacker used to issue the login.
A threat intelligence service notifies the company that a dataset matching the company's claims database schema and containing 14,000 policyholder records has appeared on a dark web forum, posted two days ago. The post includes the company's logo and a message claiming it is "sample data" with an offer to sell the full database. The security team has no prior detection alerts related to CLAIMS-DB-02 prior to the previous night's events (Event 2) — or so they believe.
Questions: What IoC category does the dark web posting represent? How does it change the understanding of the Event 2 timeline? What does "no prior alerts" actually mean in this context?
IoC category: Published/documented data. The appearance of the company's claims records on a dark web forum — with the company's logo, a description confirming the source, and a "sample" framing — is a published data IoC. The threat intelligence service's detection of this posting and notification of the company is exactly the external detection mechanism this IoC category relies on.
How it changes the Event 2 timeline: The dark web post appeared two days ago. Event 2's exfiltration was last night. This means two separate exfiltration events have occurred: the 14,000-record "sample" was exfiltrated at least 2+ days ago (likely before last night), and the 28 GB bulk transfer from Event 2 occurred last night. The attacker was inside the network before Event 2 — the 3 AM exfiltration was not the first theft. The attacker extracted a small sample first (to use as proof-of-possession for extortion), then returned for the full database. The breach timeline extends at least 2+ days before Event 2's detection, and likely much further to the initial access event.
What "no prior alerts" actually means: The absence of prior alerts does not mean the attacker was not present — it means the attacker's earlier activity did not cross any detection threshold. During the reconnaissance, lateral movement, and initial small-sample exfiltration phases, the attacker operated below alert thresholds. Either: (a) the earlier exfiltration was small enough not to trigger the bandwidth volume threshold; (b) the attacker used a different channel (DNS tunneling, slow-and-low HTTPS drip) that didn't create a visible spike; or (c) log evidence of earlier access was already deleted. The forensic response must now reconstruct how the attacker initially gained access and when — starting with reviewing all available logs (SIEM, firewall, proxy, endpoint) for the 30-day window preceding Event 2 for any trace of the initial intrusion.