Detection and Analysis

The Detection and Analysis phase is where the incident response process begins. An alert has been raised at Nexus Financial. Your job is to confirm whether a security incident has occurred, understand how the attacker got in, and determine the full extent of the damage. Every decision that you make in the upcoming rooms depends on how thoroughly this phase is completed.

Learning Objectives

• Understand what Detection and Analysis means as a NIST IR phase
• Understand how detection and analysis work together to build the full picture of an incident
• Recognize the feedback loop between detection and analysis
• Explore the common IR triggers
• Learn about team communication during an IR
• Apply detection and analysis to investigate a compromised account using Splunk

Prerequisites

• Preparation

Familiarity with Splunk SPL queries is required for the practical tasks. It is also recommended to complete the Microsoft 365 for the SOC module before starting this room.

Module Chain

This module follows a single security incident at Nexus Financial from start to finish across four rooms:

Note: This is Room 2 of 4 in the Incident Response module. The preparation gaps identified in the Preparation room are the exact vulnerabilities the attacker exploits here. What you find in this room feeds directly into the Response and Recovery room.

According to NIST SP 800-61r2, Detection and Analysis is the phase where the team responsible for incident response determines whether a security incident has occurred and builds a complete understanding of it. In large organizations, this work is handled by a dedicated IR team that is separate from the SOC. However, in many organizations, particularly smaller ones like Nexus Financial, there is no dedicated IR function. Instead, SOC analysts take on the IR role themselves. L1 analysts handle initial triage and escalation. L2 and L3 analysts lead the deeper investigation and response. The SOC team effectively becomes the IR team. At Nexus Financial, this is exactly the case. 

This phase answers two fundamental questions:

• Did a security incident occur, and how did the attacker get in?
• What is the full extent of the damage?

Think of it like a fire investigation. Detection confirms that a fire has started and is real, not a false alarm. Analysis is understanding how it started, which rooms it reached, and what damage it caused. Skipping either step means risking a fire that reignites somewhere you never checked.

Detection

Detection is the process of confirming that a security incident has actually occurred. It begins the moment a potential threat is noticed, whether through a SIEM alert, a user report, or an automated detection. Not every alert represents a real incident. The first step is always determining whether the alert is a true positive or a false positive.

In most SOC environments, detection happens across two levels:

The L1 analyst does not investigate the full incident. They confirm it exists and pass it up with enough context for the next level to take over. Your first job as the assigned L2 analyst is to validate the L1 analyst's finding without assuming it is entirely correct. From there, you extend the investigation, find what the L1 could not see from triage alone, and confirm the incident is real.

Analysis

Once an incident is confirmed, the analysis begins. Analysis is the process of understanding the full picture of what happened. This goes beyond simply confirming the incident exists. It means answering deeper questions about the attack:

• How did the attacker gain initial access?
• Which accounts and systems were affected?
• What data may have been accessed or exfiltrated?
• What actions did the attacker take after gaining access?

Scoping is a core part of analysis. It means identifying every affected account, every system accessed, and every piece of data that may have been compromised. But analysis is broader than scoping alone. It also includes correlating evidence across multiple log sources, mapping attacker behavior to known techniques, and building the complete narrative of what happened from the first malicious action to the point of detection.

Poor analysis is one of the most common causes of failed incident response. If the team does not fully understand what was compromised and how, they cannot fully eradicate the threat. An attacker who retains access to even one overlooked account or persistence mechanism can undo weeks of remediation work.

The Feedback Loop

Detection and analysis feed into each other continuously. A new IOC uncovered during analysis may reveal an additional compromised account. That account may lead to further detection of attacker activity that was previously unknown. This cycle continues until no new evidence is emerging and the full picture is confirmed with confidence.

An incident response process does not start on its own. Something must trigger it. Understanding the different sources that can initiate an IR process is important because relying on a single trigger source, such as automated SIEM alerts, creates blind spots. Incidents that do not generate an automated alert will go undetected unless other trigger sources are active.

Common IR Triggers

Each trigger source has a different detection window. A SIEM alert fires within minutes of suspicious activity. A user report may come hours later. A third-party notification could arrive days after a breach has already occurred. This is why organizations that rely on a single trigger source will always have a longer dwell time than those with multiple detection channels active. In the Nexus Financial incident covered in the upcoming tasks, the trigger was a SOC alert escalation. The alert itself was only possible because a basic geo-location detection rule existed in Splunk. Without that rule, the incident may have gone undetected entirely, which connects directly to the detection gap identified in the pentest report you reviewed in the Preparation room.

Team Communication During IR

Effective communication is as important as technical skill during an active incident. Common communication failures that slow down IR investigations include:

• Delayed escalation because no clear escalation path is defined
• Key people not being notified because contact lists are outdated
• IT teams unable to provide log access for hours due to approval processes
• MSSP or third-party providers taking days to respond to access requests
• Verbal updates that are never documented, creating gaps in the evidence trail

These delays have real consequences. Every hour an attacker remains uncontained is an hour they can use to deepen their access, exfiltrate more data, or establish additional persistence. A well-defined communication plan with clear escalation timelines directly reduces the time between detection and containment. As you saw in the Preparation room, Nexus Financial's IR policy does not currently define a maximum response time between incident declaration and initial containment, a gap that will matter in this investigation.

Ticketing systems play an important role in keeping communication organized. Every action taken, every finding made, and every decision reached during the investigation should be logged in a ticket. This creates an auditable trail that supports post-incident review and lessons learned documentation.

Two tools are essential throughout the Detection and Analysis phase: the asset inventory and the IOC Tracker. Together, they provide a structured way to map what exists in the environment and track every malicious indicator found during the investigation.

The Asset Inventory

The asset inventory is a reference document that lists all systems, devices, and platforms within the organization. During analysis, the IR team uses it to answer questions like: which systems did this account have access to? Who owns this IP address? What other accounts are associated with this workstation?

Without an accurate asset inventory, analysis becomes difficult. The team may miss affected systems simply because they did not know they existed. This is why maintaining an up-to-date asset inventory is a core preparation requirement, a gap that Nexus Financial's own inventory acknowledges, noting that mobile devices are not currently tracked.

The IOC Tracker

The IOC Tracker is a running record of every indicator of compromise discovered during the investigation. It starts with whatever triggered the incident and grows with every new finding. Each entry records the IOC type, its value, where it was found, and any relevant notes.

Common IOC types include:

The IOC Tracker is a living document. It is updated throughout every phase of the investigation. Every IOC you find in this room will carry forward into the rooms that follow.

In the Preparation room, you reviewed Nexus Financial's preparation state and found an organization with critical gaps left unaddressed. No MFA on standard user accounts, missing email authentication controls, a previous phishing incident closed without fixing the root cause, and detection rules that did not cover key threat scenarios. It looks like those gaps have now been exploited.

An anomalous sign-in alert was raised by the SIEM platform and triaged by Marcus Webb, Nexus Financial's L1 Security Analyst. Marcus confirmed the alert as a true positive and escalated it. You have been assigned to the investigation as the L2 analyst responsible for validating Marcus's findings and leading the full IR investigation.

Below is the SIEM alert that Marcus Webb received and triaged.

After triaging the alert, Marcus marked the alert as a true positive and raised the following escalation ticket.

Available Log Sources

Nexus Financial's Microsoft 365 logs have been ingested into Splunk under the index ir. The following log sources are available across all practical tasks in this module:

Lab Access

Start the lab by clicking the Start Machine button below. You will then have access to the Splunk Web interface. Please wait 4-5 minutes for the Splunk instance to launch. To access Splunk, please wait for the VM to start and follow this link:

• https://LAB_WEB_URL.p.thmlabs.com (opens in new tab)

For all the practical tasks, use the index=ir. Set the time range to All Time before running queries.

You have been handed an escalation from Marcus Webb confirming a suspicious sign-in on the Nexus Financial account l.chen@nexusfinancial.thm, belonging to Laura Chen, Finance Manager. The escalation ticket provides the corporate IP address and confirms that this sign-in originated entirely outside the United Kingdom.

This task focuses on the detection side of the phase. Your job is to confirm the suspicious activity in the logs, validate Marcus's finding, and trace the attack back to its origin. Start with the Entra ID sign-in logs. Filter for sign-in activity on Laura Chen's account and look for anything that does not match the corporate IP. Once you have confirmed the suspicious sign-in, think about how the attacker obtained Laura's credentials in the first place. Pivot to the Message Trace and look at what was delivered to her account before the suspicious sign-in occurred.

Use the log sources, sourcetypes, and fields listed in Task 5 to build your queries. The questions below will guide your investigation.

You have confirmed the initial compromise of Laura Chen's account and identified the phishing email that delivered it. This task focuses on the analysis side of the phase. Now that detection is confirmed, you need to analyze the full extent of the incident, understanding exactly what the attacker did, which other accounts were affected, and what actions were taken inside the environment after gaining access.

Search across all Nexus Financial accounts for sign-in activity from the attacker's IP. Then look beyond the sign-in logs. A threat actor who has just gained access to a mailbox will typically act quickly to secure their position before being detected. Review the Unified Audit Logs to see which operations were performed from the attacker's IP address within the environment.

Finally, go back to the Message Trace. The phishing email that compromised Laura Chen's account may not have been the only one sent. Understanding the full delivery scope tells you how many accounts were at risk from the very beginning.

Use the log sources, sourcetypes, and fields listed in Task 5 to build your queries. The questions below will guide your investigation.

In this room, we covered the Detection and Analysis phase of the NIST SP 800-61r2 incident response framework. We explored how detection and analysis work together to build the full picture of an incident. Detection confirms what happened and how the attacker got in, and analysis determines the full extent of the damage. We also saw how these two activities feed into each other continuously, how the L1 to L2 handoff works, and why communication failures during IR directly increase the time an attacker has to operate undetected.

In the practical tasks, starting with a single escalation ticket, we traced the attacker's IP address through sign-in logs, identified the phishing email that delivered the initial compromise, identified every account targeted by the campaign, and discovered the attacker's first post-compromise action within the Nexus Financial environment.

In the next room, Response and Recovery (coming soon!), the scope is confirmed. Your role shifts from understanding the incident to stopping it from getting worse and removing the attacker from the environment entirely.