Cyber Security Quiz: Incident Timeline Creation
10 questions · exam conditions
0:00
Incident Timeline CreationQuestion 1 of 10

An email contains these timestamps:

  • Date header: 17:58:00 UTC+02:00
  • Trusted gateway mx1 received the message from the external sender at 11:01:00 UTC-05:00
  • Trusted gateway mx2 received the message from mx1 at 16:03:00 UTC
  • EDR recorded the recipient opening the attachment at 16:05:00 UTC

The Date header was supplied by the sender and has not been independently validated.

Which timeline treatment is most defensible?

Place the Date header first at 15:58 UTC, followed by mx1 receipt, mx2 receipt, and attachment opening, treating the sender-supplied timestamp as the authoritative origin
Place attachment opening first, then mx2 receipt and mx1 receipt, reading delivery Received headers in top-down display order rather than normalizing timestamps
Place mx1 receipt at 16:01 UTC, mx2 receipt at 16:03 UTC, and attachment opening at 16:05 UTC; annotate the Date header as an unverified sender-supplied claim
Place mx2 receipt at 16:03 UTC, mx1 receipt at 16:01 UTC, and attachment opening at 16:05 UTC, preserving the textual order in which Received headers appear in the message
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Incident Timeline Creation

Practice Incident Timeline Creation in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Incident Timeline Creation, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An email contains these timestamps:

  • Date header: 17:58:00 UTC+02:00
  • Trusted gateway mx1 received the message from the external sender at 11:01:00 UTC-05:00
  • Trusted gateway mx2 received the message from mx1 at 16:03:00 UTC
  • EDR recorded the recipient opening the attachment at 16:05:00 UTC

The Date header was supplied by the sender and has not been independently validated.

Which timeline treatment is most defensible?

  1. Place the Date header first at 15:58 UTC, followed by mx1 receipt, mx2 receipt, and attachment opening, treating the sender-supplied timestamp as the authoritative origin
  2. Place attachment opening first, then mx2 receipt and mx1 receipt, reading delivery Received headers in top-down display order rather than normalizing timestamps
  3. Place mx1 receipt at 16:01 UTC, mx2 receipt at 16:03 UTC, and attachment opening at 16:05 UTC; annotate the Date header as an unverified sender-supplied claim (correct answer)
  4. Place mx2 receipt at 16:03 UTC, mx1 receipt at 16:01 UTC, and attachment opening at 16:05 UTC, preserving the textual order in which Received headers appear in the message
Explanation: When reconstructing an email attack timeline, your foundation must be verified, trusted sources — not attacker-controlled data. The sender supplies the Date header, meaning it can be forged, backdated, or falsified with zero technical barrier. Your timeline must reflect what trustworthy infrastructure recorded, and timestamps must be normalized to UTC before sequencing events. Converting the trusted gateway receipts: mx1 received the message at 11:01 UTC−05:00, which normalizes to 16:01 UTC. mx2 received it at 16:03 UTC. The EDR recorded the attachment opening at 16:05 UTC. This gives a clean, verified sequence — and that's exactly what C does. It sequences the three verified events chronologically and correctly demotes the Date header to an annotated, unverified claim rather than anchoring the timeline to it. A is the most dangerous choice: it treats the sender-supplied Date header (15:58 UTC after conversion) as the authoritative origin. This is precisely what a threat actor exploits — by forging timestamps to confuse responders or manipulate perceived sequence-of-events. B commits two errors simultaneously: it reverses chronological order and conflates display order of Received headers with temporal order. Email clients stack Received headers with the most recent on top, so reading them top-down produces reverse chronology, not forward. D makes essentially the same mistake as B but without the inversion — it preserves textual header order rather than correcting for it through UTC normalization and proper sequencing. Your study tip: always ask "who wrote this timestamp and can they be trusted?" Normalize everything to UTC, treat sender-supplied fields as evidence to scrutinize — not facts to accept.

Question 2

A packet capture shows that a reverse proxy forwarded request ID R-884 to an application at 09:00:00 UTC and that the application received it with negligible delay. The application log records receipt of R-884 at 09:02:15. Assume the application's clock offset remained constant. Other records show:

  • Firewall outbound connection at 09:00:20 UTC
  • Application-created shell at 09:02:40 application time
  • EDR child-process detection at 09:00:28 UTC

After correcting the application clock, which ordering is most accurate?

  1. Proxy request, application shell, firewall connection, EDR detection
  2. Application shell, proxy request, firewall connection, EDR detection
  3. Proxy request, firewall connection, application shell, EDR detection (correct answer)
  4. Proxy request, firewall connection, EDR detection, application shell
Explanation: When reconstructing attack timelines from logs, your first job is always to normalize all timestamps to a single reference clock before ordering any events. Here, the application clock is skewed: the proxy forwarded R-884 at 09:00:00 UTC, but the application logged receipt at 09:02:15 — a +2 minutes 15 seconds offset. Every application timestamp must be shifted back by 2:15 to get true UTC. Applying that correction: the application-created shell logged at 09:02:40 application time actually occurred at 09:00:25 UTC. Now you can sequence all four events on a common UTC timeline:
  • 09:00:00 — Proxy request (R-884 forwarded)
  • 09:00:20 — Firewall outbound connection
  • 09:00:25 — Application shell created (corrected)
  • 09:00:28 — EDR child-process detection
This gives you: proxy request → firewall connection → application shell → EDR detection, which is exactly answer C. Answer D is tempting but wrong — it places EDR detection before the shell, which is causally backwards; EDR detected the child process spawned by the shell, so the shell must come first. Answer A incorrectly places the application shell second, before the firewall connection, ignoring that the corrected shell time (09:00:25) falls after the firewall event (09:00:20). Answer B is the most dangerous distractor — it places the shell before the proxy request, which would only be true if you used the uncorrected application clock without thinking critically. Study tip: On timeline reconstruction questions, always convert all timestamps to UTC before ordering anything. Clock skew is a classic trap designed to trick you into sequencing events using mixed reference frames.

Question 3

An analyst is correlating four logs. All devices were synchronized, but each log uses the stated fixed offset:

  • VPN: successful authentication at 08:12:10, UTC-04:00
  • Web server: suspicious request at 14:13:40, UTC+02:00
  • EDR: PowerShell launch at 12:14:05 UTC
  • Firewall: outbound alert at 07:14:20, UTC-05:00

Which sequence should appear in the normalized UTC incident timeline, from earliest to latest?

  1. VPN authentication, EDR launch, web request, firewall alert
  2. VPN authentication, web request, EDR launch, firewall alert (correct answer)
  3. Firewall alert, VPN authentication, web request, EDR launch
  4. Web request, VPN authentication, firewall alert, EDR launch
Explanation: When correlating logs across systems, your first move is always normalize every timestamp to UTC. Each offset tells you how far that local time is from UTC — add the offset if it's negative (behind UTC), subtract if it's positive (ahead of UTC). Here's the conversion for each event:
  • VPN (UTC-04:00): 08:12:10 + 4 hours = 12:12:10 UTC
  • Web server (UTC+02:00): 14:13:40 − 2 hours = 12:13:40 UTC
  • EDR: Already UTC = 12:14:05 UTC
  • Firewall (UTC-05:00): 07:14:20 + 5 hours = 12:14:20 UTC
Sorted earliest to latest: VPN (12:12:10) → Web request (12:13:40) → EDR (12:14:05) → Firewall (12:14:20). That matches answer B, which is correct. Answer A is wrong because it places the EDR launch before the web request — the opposite of what the normalized times show. Answer C incorrectly lists the firewall alert first; before normalization, its raw time (07:14:20) looks earliest, but once you add the UTC-05:00 offset it becomes 12:14:20, making it the last event. This is the classic trap — never compare raw timestamps across different offsets. Answer D is entirely wrong in ordering, placing the web request first and EDR last, which contradicts both the raw and normalized times. The key study habit here: when you see mixed UTC offsets, convert everything before drawing any conclusions. A timestamp like 07:14 in UTC-05:00 is actually later than 08:12 in UTC-04:00 — raw times across zones are meaningless without normalization.

Question 4

A DHCP server provides these authoritative lease records for 10.20.4.44:

  • 09:00:00: leased to MAC address AA-AA-AA-AA-AA-AA
  • 09:47:10: lease released
  • 09:48:00: leased to MAC address BB-BB-BB-BB-BB-BB

A DNS sensor records a malicious query from 10.20.4.44 at 09:46:30. A firewall records a connection from the same IP address at 09:49:15.

Which attribution should the incident timeline make?

  1. Attribute both events to MAC AA because it held the first observed lease
  2. Attribute both events to MAC BB because it held the most recent lease
  3. Attribute neither event because a reused IP address cannot support temporal attribution
  4. Attribute the DNS query to MAC AA and the firewall connection to MAC BB (correct answer)
Explanation: When correlating network events to specific devices, the key skill is temporal mapping — you must match each event's timestamp to whichever DHCP lease was active at that exact moment, not the first or most recent lease overall. Look at the timeline carefully. MAC AA held the lease from 09:00:00 until it was released at 09:47:10. The DNS query occurred at 09:46:30 — which falls inside AA's lease window. MAC BB didn't receive the IP until 09:48:00, and the firewall connection occurred at 09:49:15 — clearly inside BB's lease window. This makes D the correct attribution: the DNS query belongs to MAC AA, and the firewall connection belongs to MAC BB. Answer A fails because "first observed lease" is not a valid attribution rule. Applying AA's identity to the firewall event at 09:49:15 is factually wrong — AA had already released the address 87 seconds earlier. Answer B makes the same logical error in reverse: BB didn't exist on that IP during the DNS query, so attributing that event to BB is an anachronism. Answer C is the most tempting distractor — it sounds appropriately cautious — but it overcorrects. IP reuse does complicate attribution, but authoritative DHCP lease records with precise timestamps resolve that ambiguity. Claiming attribution is impossible when you have complete lease data is simply incorrect. Your study tip: on attribution questions, always build a timeline with explicit start/end boundaries for each lease, then ask "who owned this IP at this second?" Timestamp overlap is everything.

Question 5

A host booted while its wall clock was five minutes slow. At system uptime 20 seconds, it logged a suspicious process at wall-clock time 03:55:20. At uptime 40 seconds, NTP moved the wall clock forward five minutes. An accurately synchronized network sensor recorded the host's first related connection at 04:00:30 UTC.

What chronology should the analyst derive by correlating wall-clock and uptime evidence?

  1. The process occurred at 03:55:20, and the network connection followed five minutes ten seconds later
  2. The process occurred at approximately 04:00:20, and the network connection followed about ten seconds later (correct answer)
  3. The network connection occurred at 04:00:30, and the process followed when NTP corrected the clock
  4. The process and connection are simultaneous because the five-minute correction eliminates elapsed time
Explanation: When correlating timestamps across systems with clock skew, your job is to anchor all events to a single reliable time reference — in this case, the NTP-corrected clock and uptime counter, which together let you reconstruct true event times regardless of what the wall clock displayed at any given moment. Here's the key insight: uptime is independent of wall-clock corrections. The host's uptime counter simply measures seconds since boot. The suspicious process was logged at uptime 20 seconds. NTP corrected the clock at uptime 40 seconds, jumping wall time forward by five minutes. This tells you the pre-correction wall clock was five minutes slow. So the true UTC time at boot was approximately 04:00:00, meaning uptime 20 seconds corresponds to approximately 04:00:20 UTC — which is when the process actually occurred. The network connection was recorded by an accurate sensor at 04:00:30 UTC, placing it about ten seconds after the process. That's exactly what B describes, making it correct. A is wrong because it accepts the uncorrected wall-clock timestamp (03:55:20) at face value, ignoring that the clock was five minutes slow — a classic clock-skew trap. C inverts the chronology entirely, implying the connection preceded the process, which contradicts both the uptime evidence and basic cause-and-effect logic. D misunderstands NTP correction: jumping the clock forward doesn't collapse elapsed time or make events simultaneous — it simply relabels when those events occurred on the corrected scale. As a study strategy, whenever you see clock skew scenarios, immediately convert all wall-clock timestamps using uptime as your ground truth. Uptime never jumps — wall clocks do.

Question 6

A suspicious executable has an NTFS creation timestamp of 20:10:00 UTC and a modification timestamp from two years earlier. EDR records the executable starting at 20:12:04 UTC, a prefetch artifact reports a last-run time of 20:12:05 UTC, and the firewall records its first outbound connection at 20:12:06 UTC. Investigators confirm that the file was copied from removable media.

Which timeline interpretation is best supported by the evidence?

  1. The file arrived around 20:10, executed around 20:12:04, and initiated a connection around 20:12:06 (correct answer)
  2. The file arrived two years earlier, was copied at 20:10, and first executed at the prefetch time
  3. The file executed at 20:10, was detected by EDR at 20:12:04, and was modified two years earlier
  4. The file arrived at 20:12:05, executed at 20:12:06, and connected before the firewall recorded it
Explanation: When building a forensic timeline, you need to understand what each artifact actually records — and when artifacts conflict, you look for the most coherent story supported by the most reliable sources. Here, the NTFS creation timestamp shows 20:10:00 UTC, which records when the file was written to this filesystem — consistent with copying from removable media at that time. The older modification timestamp (two years prior) is a timestomping indicator or simply reflects the file's original creation date on the source media; it does not mean the file existed on this system two years ago. EDR catching process execution at 20:12:04, prefetch logging last-run at 20:12:05, and the firewall logging outbound traffic at 20:12:06 form a tight, causally logical sequence: copy → execute → connect. Answer A captures this perfectly. Answer B is wrong because it misreads the old modification timestamp as evidence the file arrived two years ago — that's a classic timestomping trap. The NTFS creation timestamp on the destination drive is far more reliable for determining file arrival. Answer C incorrectly places execution at 20:10, which is when the file was copied, not when the process started. EDR and prefetch both contradict this ordering. Answer D inverts the sequence entirely — prefetch records last run, not arrival, and nothing in the evidence places arrival at 20:12:05. Study tip: Always anchor your timeline to filesystem creation timestamps on the destination volume for file arrival, and treat suspiciously old modification timestamps as a red flag for tampering rather than reliable history.

Question 7

An endpoint agent assigns monotonically increasing record IDs before transmitting events. It produced the following records:

  • ID 781: process creation at local time 03:10:20
  • The operating-system clock was then adjusted backward by 90 seconds
  • ID 782: outbound connection at local time 03:08:55
  • ID 783: file deletion at local time 03:09:02

Because of batching, the SIEM received the records in the order 783, 781, 782.

How should the analyst order these events in the incident timeline?

  1. Process creation (781), outbound connection (782), file deletion (783), treating monotonic record IDs as the authoritative sequence across the clock rollback (correct answer)
  2. Outbound connection, file deletion, process creation, treating the displayed local wall-clock times as authoritative
  3. File deletion, process creation, outbound connection, treating SIEM receipt order as the authoritative event sequence
  4. Process creation, file deletion, outbound connection, using record IDs for the first event but SIEM receipt order for the remaining two
Explanation: When correlating events across a clock adjustment, you need to ask: which timestamp source is immune to manipulation or drift? Monotonically increasing record IDs are assigned sequentially by the agent before any clock correction occurs, making them a reliable proxy for true event ordering — even when the wall clock is rolled back. Here's the logic: ID 781 was stamped first, so process creation happened first. The OS clock then jumped backward 90 seconds, meaning the next two events were assigned timestamps that appear earlier in the day despite occurring later in real time. IDs 782 and 783 confirm outbound connection came second and file deletion third. Answer A correctly uses this monotonic sequence — 781 → 782 → 783 — as the authoritative timeline, giving you: process creation, outbound connection, file deletion. B is the most dangerous distractor. Using wall-clock timestamps after a backward clock adjustment produces a paradox: events 782 and 783 appear to precede 781, even though they happened after it. Displayed local time becomes untrustworthy the moment the clock is adjusted. C compounds the problem by using SIEM receipt order, which reflects network batching and delivery delays — entirely unrelated to when events actually occurred on the endpoint. D is a hybrid that mixes two incompatible sequencing methods with no logical basis, producing an order (781, 783, 782) that contradicts both the IDs and timestamps. Study tip: On exam questions involving log correlation, always identify which timestamp source is immutable. Receipt order reflects infrastructure, wall-clock time reflects OS state, but monotonic IDs reflect agent-assigned sequence — and agent sequence wins when the clock is unreliable.

Question 8

A firewall creates event UUID 7F91 for a permitted connection at 14:00:01 UTC. A collector wraps the same UUID in a forwarding record at 14:03:22 UTC, and the SIEM indexes it at 14:05:10 UTC. A destination server records the corresponding request at 14:00:02 UTC.

What is the most appropriate representation in the incident timeline?

  1. Record three separate network connections followed by the destination-server request
  2. Record one connection at 14:00:01, then the server request, while retaining later ingestion times as metadata (correct answer)
  3. Record one connection at 14:05:10, then place the server request before it as a precursor
  4. Record the collector event at 14:03:22 and discard both the source and indexing timestamps
Explanation: When building incident timelines in a SIEM environment, your goal is to reconstruct when events actually occurred, not when they were logged or ingested. Log forwarding pipelines always introduce latency — collectors batch events, networks add delay, and indexing takes time. A well-constructed timeline anchors events to their originating timestamps while preserving ingestion metadata for audit purposes. In this scenario, the firewall generated event UUID 7F91 at 14:00:01 UTC — that is when the permitted connection genuinely happened. The destination server independently corroborates this with its own record at 14:00:02 UTC, just one second later, which is physically consistent with a real network connection. Option B correctly places the connection at 14:00:01, sequences the server request immediately after, and retains the 14:03:22 and 14:05:10 timestamps as metadata. This gives analysts both an accurate timeline and a complete provenance record. Option A is wrong because there is only one connection — UUID 7F91 appears in multiple pipeline stages, but those are processing records of the same event, not three distinct network connections. Recording them separately would fabricate activity that never occurred. Option C inverts causality entirely: placing the server request before the connection it belongs to implies the server responded before the firewall permitted anything, which is logically impossible. Option D discards both the original firewall timestamp and the SIEM index time, destroying forensic provenance for no analytical benefit. As a study tip, whenever a question gives you multiple timestamps for the same event UUID, recognize that pipeline latency is the concept being tested — always anchor your timeline to the event-origin timestamp, and treat later timestamps as metadata, never as replacements.

Question 9

Three independent systems have a documented maximum clock error of plus or minus three seconds. They report:

  • DNS query at 13:00:00 UTC
  • PowerShell launch at 13:00:01 UTC
  • Proxy download at 13:00:02 UTC

No transaction ID, process lineage, or other causal identifier links the records.

How should these events be represented in a rigorous incident timeline?

  1. Order DNS, PowerShell, and download because the displayed timestamps differ by one second
  2. Order PowerShell, DNS, and download because process execution must precede name resolution
  3. Order DNS, download, and PowerShell because a completed download must precede execution
  4. Retain the reported times but mark their relative order as unresolved because their uncertainty intervals overlap (correct answer)
Explanation: When building an incident timeline, you must account for timestamp uncertainty before drawing conclusions about event order. Each clock has a documented error of ±3 seconds, meaning any single timestamp could be off by up to 3 seconds in either direction. Two events separated by fewer seconds than the combined uncertainty window cannot be reliably ordered — their true occurrence times may have been reversed, simultaneous, or exactly as reported. Here, the three events span only 2 seconds total (13:00:00 to 13:00:02), but each clock carries ±3 seconds of error. The uncertainty intervals of all three events overlap completely, meaning any ordering is equally plausible given the data. Without a causal identifier — a transaction ID, process lineage, or shared session token — you have no independent mechanism to resolve the ambiguity. D is correct because it honestly reflects this: retain the reported timestamps but explicitly flag the relative order as unresolved. A is wrong because it treats a 1-second difference between timestamps as meaningful when the clock error alone is ±3 seconds. The difference is entirely within the noise floor. B commits a different error — it substitutes assumed operational logic ("execution must precede name resolution") for actual evidence. Reasoning from how attacks typically work is a hypothesis, not a timeline fact. C makes the same logical mistake in reverse, inferring order from assumed causality rather than verified data. For any timeline question, ask yourself: does the evidence establish order, or am I assuming it? When clock skew exceeds the gap between events and no causal link exists, the rigorous answer is always to acknowledge uncertainty rather than manufacture a sequence.

Question 10

During an investigation, the available records show:

  • 05:50 UTC: successful remote authentication for the user's account
  • 06:05 UTC: proxy download of a suspicious payload
  • 06:15 UTC: endpoint agent restarts after a logging outage
  • 06:20 UTC: endpoint records its first beacon from the payload

No endpoint telemetry is available before 06:15, and the authentication may have been legitimate.

Which timeline conclusion is appropriately scoped to the evidence?

  1. Initial compromise occurred at 05:50 UTC, because the successful authentication is the earliest relevant record and sufficient to establish the start of the incident
  2. Payload execution occurred at 06:05 UTC, because the proxy download record at that time is sufficient to confirm both delivery and immediate execution
  3. The payload was downloaded no later than 06:05 UTC and was active no later than 06:20 UTC, but the exact execution time and whether initial access was malicious remain uncertain given the evidence gaps (correct answer)
  4. Initial compromise is confirmed at 06:20 UTC, because the endpoint beacon is the first directly observed malicious activity and earlier records cannot establish compromise
Explanation: When building incident timelines, your job is to represent what the evidence actually supports — not to fill gaps with assumptions. Investigators are often tempted to anchor on the earliest suspicious record or the first confirmed malicious event, but both instincts can mislead you when evidence is incomplete. Answer C is correct because it precisely maps each observable fact to its appropriate certainty level. The proxy log confirms the payload existed and was downloaded by 06:05 — that's a hard upper bound on delivery. The beacon at 06:20 confirms the payload was running by that time. Crucially, C acknowledges two genuine unknowns: when exactly the payload executed (any time between 06:05 and 06:20, during the logging gap), and whether the 05:50 authentication was malicious or legitimate. This is appropriately scoped forensic reasoning. Answer A overclaims by treating the authentication event as sufficient proof of compromise. A successful login could be the attacker — or the legitimate user. Without corroborating evidence, declaring it the start of the incident is speculation dressed as conclusion. Answer B makes a double error: it conflates download with execution. A proxy download record confirms delivery, not that the payload ran immediately. These are distinct forensic milestones, and assuming simultaneity ignores the logging gap entirely. Answer D artificially ignores earlier records. The beacon at 06:20 is the first endpoint-confirmed malicious event, but investigators cannot simply discard prior logs because they're ambiguous. Prior records still bound the timeline; they just carry uncertainty. Your study tip: in timeline questions, the correct answer almost always matches the strength of evidence — strong claims require strong records, and honest uncertainty is never a weakness.