Identification & Scoping — Incident Response — TryHackMe Walkthrough & Insights

A look into the second phase of the Incident Response Framework, Identification & Scoping.

Room URL: https://tryhackme.com/room/identificationandscoping

Task 1 Introduction

Welcome to the Identification and Scoping phase of the TryHackMe Incident Response module. Just as you’ve joined us at SwiftSpend Financial (SSF), we’ve already received notifications about a potential security compromise. There’s no time to lose — we must promptly identify the nature of the breach and the scope of its extent!

In this room, we will introduce you to a crucial tool for incident response — the Spreadsheet of Doom (SoD), a comprehensive directory of malicious indicators that can streamline our investigation process.

Learning Objectives

This room covers how we identify and scope security incidents, interpret security alerts and logs, gather additional evidence, and effectively use the Asset Inventory and Spreadsheet of Doom to identify and scope the extent of a security incident.

• Identify the nature of security alerts.
• Understand the process of gathering additional evidence.
• Learn the importance of having an Asset Inventory and the Spreadsheet of Doom in incident response.
• Discover how to scope the extent of a security compromise.
• Understand the feedback loop between Identification and Scoping in incident response.

Room Prerequisites

Before starting with this room, we recommend you clear the Preparation room, the first part of our Incident Response module.

https://medium.com/@iritt/preparation-incident-response-tryhackme-walkthrough-insights-6edb68a9c738

Join us in this immersive module, where you will develop the expertise needed to promptly identify security compromises and scope their extent, fortifying the security posture of assets across diverse platforms.

Answer the questions below

I’m ready to identify the scope and extent of this security incident.

Task 2 Identification: Unearthing the Existence of a Security Incident

Connecting to the machine

Start the virtual machine in split-screen view by clicking the green Start Machine button on the upper right section of this task. If the VM is not visible, use the blue Show Split View button at the top-right of the page. Alternatively, you can connect to the VM via RDP using the credentials below if Split View does not work.

Username analyst Password DFIR321! IP MACHINE_IP

RDP Connection

xfreerdp /v:MACHINE_IP /u:analyst /p:DFIR321!

IMPORTANT: The attached VM contains artefacts to help us better understand a Security Incident from detection to resolution. Work on the subsequent tasks and experiment with the VM through a case example. Microsoft Outlook will start on its own. Kindly ignore the activation key window by pressing Back, and then proceed by clicking Skip sign in for now ▶️ Use as view only. When asked for a license, click X, for optional data, click Next ▶️ Don't send optional data ▶️ Done in the subsequent pop-up windows.

The Identification phase forms the bedrock of the Incident Response Process. This critical phase combines the technical detection of potential security incidents with the inherent human capacity to recognise and report them.

The speed at which an organisation can spot an incident directly correlates with the pace of response, potentially limiting the damage and shortening recovery time.

The Triad of Identification: People, Process, and Technology

Identification is a harmonious concert between people, processes, and technology.

While technology offers the tools to detect potential incidents through alerts, people must interpret these alerts and adhere to established procedures to ensure incidents are correctly identified and managed.

Moreover, all, not solely the IT or Security teams, must report any anomalies and ensure that the relevant parties are alerted by following the appropriate procedures.

Consequently, the success of the identification phase rests on a well-coordinated collaboration among these three elements.

Understanding Security Alerts and Event Notifications

Security Alerts, also referred to as Event Notifications, are crucial signals that may hint at the presence of a potential threat or the occurrence of an actual security incident. These are pivotal in triggering the Incident Response Process and ensuring security and safety.

Understanding the nature of these alerts, including their type and severity, is vital in guiding the incident response process. This understanding is nurtured through technical expertise, effective use of security tools, and a culture of continuous learning and vigilance.

Following the proper procedures when handling these alerts ensures that the right individuals are alerted, bolstering incident response effectiveness.

Leveraging Technical Expertise and Security Tools

Effective incident response relies on timely reporting, staff proficiency, and strategic use of security technologies.

Therefore, it’s crucial that all employees of an organisation, technical or otherwise, stay alert and promptly report any suspicious activities or anomalies through the appropriate communication channels.

Employing robust security technologies can significantly enhance the detection and deterrence of potential threats, ensuring rapid recognition and response to situations that may escalate into actual security incidents.

It is why TryHackMe is dedicated to supporting those pursuing a career in Blue teaming to master security tools by offering a platform that can aid individuals in developing proficiency in areas specific to Security Operations and Incident Response tooling, such as the following:

• Endpoint Detection and Response (EDR)
• Intro to Endpoint Security
• Aurora EDR
• Wazuh
• Intrusion Detection and Prevention Systems (IDPS)
• Snort
• Snort Challenge — The Basics
• Snort Challenge — Live Attacks
• Security Information and Event Management (SIEM)
• Investigating with ELK 101
• Splunk: Basics
• Incident handling with Splunk

Recognising that these security tools truly flourish in the hands of skilled individuals with the necessary information and technical expertise to combat potential threats and manage security incidents is vital.

However, effective communication channels are just as essential to ensure that the right people are quickly alerted with accurate and precise information, which enables them to conduct an investigation and initiate the incident response process, made possible only by well-designed procedures that both technical and non-technical staff can swiftly and seamlessly follow.

Promoting a Culture of Learning and Vigilance

Cultivating a culture of learning and vigilance is a top-down initiative. Executive management must prioritise and invest in cyber security, setting clear expectations for following the correct procedures.

Regular education and awareness campaigns can equip personnel to identify and report suspicious activity or technical anomalies they may encounter, contributing to the overall effectiveness of the incident response process.

Moreover, comprehensive policies and procedures related to incident response and reporting, guided by legal counsel, can underscore the importance of following the right procedures in identifying security incidents and communicating them effectively, thereby alerting the relevant people with the necessary information that will enable them to address issues.

Transitioning from Identification to Scoping

Once an incident has been identified, the subsequent step is determining its scope.

Scoping involves grasping the extent of the incident, including which systems are affected, what data is at risk, and how the incident impacts the organisation.

The transition from identification to scoping is crucial in the Incident Response Process, demanding clear communication, effective collaboration, and a well-defined process. The insights gained from the identification phase will prove instrumental in facilitating this transition and strengthening the effectiveness of the incident response process.

Answer the questions below

2.1 What is the Subject of Ticket#2023012398704232?

Open Ticket#2023012398704232 Email.

Look at the “Ticket Subject” field.

Answer: Weird Error in Outlook

2.2 According to your colleague John, the issue outlined on Ticket#2023012398704232 could be related to what?

In John’s email, he suspects that the issue might be due to missing email security configurations (SPF, DKIM, and DMARC) on the mail server.

• SPF Verifies sending mail serversPrevents spoofing from unauthorized mail servers
• DKIM Adds a digital signatureEnsures email integrity (no tampering)
• DMARC Enforces SPF/DKIM & reports failuresStops phishing & provides reports

Answer: SPF, DKIM & DMARC records

• DMARCEnforces SPF/DKIM & reports failuresStops phishing & provides reports

2.3 Your colleague requested what kind of data pertaining to the machine WKSTN-02?

Task 3 Scoping: Understanding the Extent of a Security Incident

After identification, the next critical step in the Incident Response Process is Scoping, which involves determining the extent of a security incident, including identifying the affected systems, the type of data at risk, and the potential impact on the organisation.

Scoping is essential as it guides the subsequent steps of the response process and helps formulate an effective mitigation strategy.

The Asset Inventory: A Quick Reference for Incident Response

The Asset Inventory is a crucial tool in the incident response process. It provides a comprehensive list of all the organisation’s assets, aiding in identifying and scoping potential threats. Let’s look at a simple representation of the Asset Inventory.

The Spreadsheet of Doom (SoD): Enriching Artefacts for Effective Incident Response

Identifying, understanding, and responding to potential threats within the known scope of a security incident as swiftly as possible is critical.

The Spreadsheet of Doom (SoD) is designed to aid in these processes, acting as a consolidated, organised source of information about known threats.

It serves as a single reference point, accelerating the incident response procedure. Each row in this spreadsheet is representative of a unique threat identifier or an Indicator of Compromise (IoC).

The SoD is essentially a structured list of IoCs, including IP addresses, domain names, URLs, file hashes, and more associated with malicious activity. The data in this spreadsheet is enriched with additional information about each IoC, such as its source, the type of threat it is linked to, and more.

This additional context can aid incident responders in quickly understanding the nature of a security incident and potential threats. Moreover, it provides a historical reference that can be used for tracking recurring threats and observing patterns in cyberattacks.

The SoD is more than just a list — it’s a dynamic, comprehensive resource that centralises crucial information, streamlines communication among incident response teams, and ultimately empowers faster, more effective responses to potential threats.

The Asset Inventory and Spreadsheet of Doom are indispensable tools in Scoping the extent of a security incident. These tools can be used as quick references and fact sheets, enabling efficient correlation and enrichment of artefacts by providing a comprehensive overview of relevant information about an incident at a glance. By continually updating and referring to both tools, incident response teams can stay one step ahead and take a more proactive approach to incident response.

Answer the questions below

3.1 Based on Ticket#2023012398704231 and Asset Inventory shown in this task, who owns the computer that needs Endpoint Protection definitions updated?

The Asset Inventory shows that LPTP-01 (172.16.1.153) is a Windows 10 Pro device owned by Derick Marshall.

The ticket #2023012398704231 specifically mentions that LPTP-01 has outdated Endpoint Protection definitions.

Answer: Derick Marshall

3.2 Based on the email exchanges and SoD shown in this task, what was the phishing domain where the compromised credentials in Ticket#2023012398704232 were submitted?

The SoD (Spreadsheet of Doom) lists this domain as a Phishing domain linked to Ticket#2023012398704232.

Answer: b24b-158–62–19–6.ngrok-free.app

3.3 Based on Ticket#2023012398704233, what phishing domain should be added to the SoD?

The details of Ticket#2023012398704233, which mentions a suspicious email that contains a link.
The email contains a phishing URL: https://kennaroads.buzz/data/Update365/office365/40e7baa2f826a57fcf04e5202526f8bd/?email=zoe.duncan@swiftspend.finance&error

The domain kennaroads.buzz is used in the URL, indicating it is likely a phishing domain trying to steal Office365 credentials.

Answer: kennaroads.buzz

Task 4 Identification and Scoping Feedback Loop: An Intelligence-Driven Incident Response Process

The Identification and Scoping phase of the Incident Response Process is not a linear progression but a feedback loop continually refining our understanding of the incident and its scope.

This loop becomes intelligence-driven when it leverages current investigation data, enriching it with information from past incidents, correlated logs from various data sources, advanced analytics and machine learning to enhance awareness by adding more context to a developing situation.

1. Event Notification
2. The loop begins when an issue has been reported. It triggers the incident response process and sets the stage for the subsequent steps.
3. Documentation
4. The underlying issue is documented in detail, including information about the nature of the incident, the systems affected, and any potential threats or vulnerabilities. Documentation is a critical step that provides a foundation for the rest of the process.
5. Evidence Collection
6. Evidence of the incident is collected, including log files, network traffic data, and other relevant information. The collected evidence provides valuable insights into the incident and helps identify potential threats.
7. Artefact Identification
8. The collected evidence is analysed to identify artefacts related to the incident. These artefacts can provide clues about the threat’s nature and the damage’s extent.
9. Pivot Point Discovery
10. Based on the identified artefacts, new areas of investigation may be discovered. These pivot points can lead to new insights and help further refine the incident’s scope. After this step, the process loops back to the documentation phase, incorporating the new findings.

The Power of an Intelligence-Driven Feedback Loop

A feedback loop driven by intelligence in the Identification and Scoping phase encourages a proactive and dynamic method towards incident response.

This proactive approach facilitates an ongoing education and exchange of information, enabling organisations to respond to security incidents and safeguard their systems efficiently.

It also ensures compliance with legal obligations for privacy and data protection.

Organisations can boost their incident response prowess and efficiently counteract security incidents by capitalising on real-time data concerning emerging threats, cultivating an environment of ongoing education and exchange of information, and guaranteeing privacy and data protection.

Answer the questions below

4.1 Concerning Ticket#2023012398704232 and according to your colleague John, what domain should be added to the SoD since it was used for email spoofing?

The email headers show that the spoofed email was received from “emkei.cz (89.187.129.25)”.

This indicates that emkei.cz was used as the mail server to send the spoofed email.

The email was spoofed to appear as coming from “alex.swift@swiftspend.finance”.

This further confirms that emkei.cz was used for impersonation.

Since emkei.cz is a known service used for email spoofing, it should be added to the SoD (Spreadsheet of Doom) as a source of malicious activity.

Answer: emkei.cz

4.2 Concerning the available artefacts gathered for analysis of Ticket#2023012398704232, who is the other user that received a similar phishing email but did not open a ticket nor report the issue?

From the email provided by Damian Hall, we can confirm the email spoofing attack that occurred in Ticket#2023012398704232.

The Spoofed Email Address:

“alex.swift@swiftspend.finance” does not exist, but was used in a phishing attempt.

The legitimate email is “alexander.swift@swiftspend.finance”.

Another Spoofed Email:

“mike.ascot@swiftspend.finance” is also non-existent but was used to send an email.

Attack Method:

The attackers used non-existent email addresses to send messages, likely as part of a phishing attack or an attempt to bypass security controls.

Answer: alexander.swift@swiftspend.finance

4.3 Concerning Ticket#2023012398704232, what additional IoC could be added to the SoD and be used as a pivot point for discovery?

From the email message trace CSV file, we have identified a new sender involved in the phishing attack.

A new suspicious sender email:

sales.tal0nix@gmail.com sent emails to:

• alexander.swift@swiftspend.finance (No subject)
• michael.ascot@swiftspend.finance (No subject)

The suspicious sender is using a Gmail address:

This suggests an attempt to bypass email security controls by using a generic email provider.

Phishing emails related to the “Proposal From United Trust Company Limited”:

Sent by:

• alex.swift@swiftspend.finance (Spoofed)
• mike.ascot@swiftspend.finance (Spoofed)

sales.tal0nix@gmail.com (Malicious Sender)

While this is an email address and not a domain, it should be monitored for phishing attempts.

Additionally, the previously identified phishing domain should also be added:

kennaroads.buzz (Phishing Domain)

This domain was used in Ticket#2023012398704233, where a phishing email redirected users to a fake Office365 login page.

Answer: sales.tal0nix@gmail.com

4.4 Based on the email exchanges and attachments in those exchanges, what is the password of the compromised user?

Phishing Domain Accessed:

The logs show that Michael Ascot visited b24b-158–62–19–6.ngrok-free.app on port 443 (HTTPS).

This confirms that he interacted with a phishing website.

Credential Submission Captured:

The logs contain an HTTP POST request to the phishing site:

Answer: Passw0rd!

Task 5 Conclusion

The Identification and Scoping phase of the Incident Response Process is a critical juncture that requires a well-coordinated effort between people, processes, and technology. Here, the nature of security alerts is discerned, and the extent of the incident is determined.

This phase is a balancing act, requiring technical expertise, effective use of security tools, and a culture of continuous learning and vigilance.

We’ve explored the importance of understanding security alerts, the role of technical expertise and security tools, and cultivating a culture of learning and vigilance. We’ve also delved into the significance of following proper procedures to ensure that incidents are accurately identified and managed, ensuring that the appropriate individuals capable of addressing them are notified.

Remember, the success of the identification phase hinges on a well-orchestrated collaboration between these elements. You can significantly enhance your organisation’s incident response capabilities by fostering a culture of awareness and vigilance and leveraging the right tools and processes.

Next Steps

Now that you’ve comprehensively understood the Identification and Scoping phase, it’s time to proceed to the next room, Intel Creation and Containment.

Here, you’ll delve deeper into the Incident Response Process, exploring the subsequent phases and honing your skills further. Remember, continuous learning and practice are essential to mastering incident response. Onwards!

Answer the questions below

I’ve completed the Identification and Scoping room.

Final Thought

This room explains how to detect and investigate security incidents in an organization. It focuses on phishing attacks, analyzing logs, and understanding how attackers steal credentials.

1. Identifying the Security Incident

A user received a suspicious email from an address that does not exist. The email came from a service known for sending fake emails. The company did not have proper email security settings, so the email was not blocked.

Conclusion: The attacker successfully sent fake emails, and employees may have fallen for the phishing attack.

2. Investigating the Impact (Scoping)

The security team used a spreadsheet to track the attack. They found:

• Malicious websites that were used for phishing.
• An IP address linked to a known attacker.
• An email address used to send phishing messages.

Conclusion: The phishing attack was planned to steal login credentials from employees.

3. Checking Who Got Hacked

A company employee clicked on a phishing link and entered his login details. The security logs showed that his username and password were sent to the attacker. The attacker now has access to the employee’s account.

Conclusion: The employee’s credentials were stolen, and an attacker could now use them to access company data.

4. Stopping the Attack

The IT team blocked the phishing websites and the fake email sender. The affected employee was forced to change his password. Multi-Factor Authentication was enabled to prevent attackers from using stolen credentials.

Conclusion: The company responded quickly, blocked the attack, and secured the affected account.

5. Learning from the Attack

The security team updated their tracking system with details of the phishing attack. The organization improved its email security settings to prevent similar attacks. Employees were trained to recognize phishing emails and avoid clicking on unknown links.

Conclusion: The organization improved its security and trained employees to prevent future phishing attacks.

Key Takeaways

• Phishing emails can trick employees into revealing passwords.
• Security logs help identify who was hacked and what data was stolen.
• Blocking malicious websites and forcing password changes can stop attackers.
• Training employees is important to prevent future attacks.

Cybersecurity is a shared responsibility — stay alert, verify every email, and think before you click. A moment of caution can prevent a major security breach.