Report Writing for SOC L2 (TryHackMe)

Introduction

As you move into a senior (Level 2) analyst role, the scope of your responsibilities shifts. Technical alert triage is still part of the job, but your findings now need to reach people beyond the SOC, through formal case reports. This room explores the report writing skills that make you effective at the Level 2 role and beyond.

Learning Objectives

• Understand the purpose and value of professional reports

• Explore SOC report templates for various target audiences

• Learn how AI helps with report writing, and what the pitfalls are

• Practice the acquired knowledge in two interactive simulations

Prerequisites

• No formal prerequisites, but the room suits best for L1+ analysts

L1 vs L2 Communication

Responsibilities of Level 2

SOC Level 2 is as much about communication as it is about technical skill. L1 analysts can do an outstanding job triaging alerts, but if those findings aren't communicated clearly, they have no value in the real world. As L2, your job is to turn SOC notes into something actionable: a precise summary report that colleagues, customers, or management can act on. Your report writing skills can decide whether an intrusion is stopped in time.

L2 reports must sound credible and professional. Your report is how the outside world sees your SOC.

In most SOC teams, L1 analysts communicate almost exclusively within the team itself: writing ticket notes, escalating alerts, and handing off to colleagues. For L2 analysts, this changes significantly: the role carries broader responsibility, and with it comes a higher need for soft skills. Depending on the organization and the severity of an incident, an L2 analyst may find themselves communicating with:

• Top management (C-level): To present an incident summary or a quarterly SOC report

• External MSSP customers: To report a detected intrusion and agree on next steps

• DFIR, CTI, or InfoSec teams: To hand over the SOC findings and attack indicators

You will need to adjust your writing style for the right audience to succeed in a SOC

L2 Report Types

The L1 analysts don't create formal external reports and operate around short alert comments and escalation notes (200-500 characters per alert). During routine days, the L2 analysts don't go beyond that metric, too. But when something serious happens, they might need to write more formal reports, such as:

• Case summary for C-level:  A business-focused, non-technical overview of the incident that occurred

• Email to the MSSP customer: A formal, actionable summary of what happened and what to do next

• DFIR team handover notes: A list of your findings from SIEM/EDR to help the bigger forensics efforts

In the next tasks, we will explore best practices for every type of SOC L2 communication

Communication Channels

Lastly, L2 analysts need to choose the right channel for reporting. Let's see the common options below:

Channel	Purpose
Voice Call	Used for urgent situations requiring an immediate response. For accountability, phone or Zoom calls are typically followed up with an email summary.
Email Letter	Security-related updates and incidents should always be communicated via email, with all relevant parties copied (CC) to ensure a clear audit trail.
Ticketing System	Bigger MSSPs have dedicated ticketing systems and customer portals (e.g. Jira ITSM) that are used instead of regular email threads.
Corporate Chat	Ideal for internal and informal discussions. Same as with voice calls, key decisions and incident findings should still be summarized via email.

Note: Every company builds its own workflows, so the table above might not be applicable to every SOC or MSSP.

Answer the questions below

Which SOC tier, L1 or L2, bridges the SOC and the outside world? L2

What do L2 analysts write to summarize SOC findings (one word)? Reports

Leadership Communication

Reporting to Company Leadership

The internal SOC team always reports to a C-level position, such as CTO, CISO, or even CEO. Whenever your SOC handles (or misses) an intrusion that causes business impact, you need to explain it to the leadership. You might also need to prepare periodic reports on SOC effectiveness or write a formal request to purchase or replace a security solution. The key rules you need to remember during C-level communication are:

• Focus on business: Focus on what's important for the company, not just SOC.

• Use formal tone: Speak and write as an independent expert, not as an old friend.

• Keep it simple: Avoid jargon and terminology; your audience is non-technical.

• Talk in facts: Keep evidence for your statements (screenshots, snapshots, links).

• Don't panic: During incidents, show that the situation is fully under SOC control.

Contacting MSSP Customers

If your SOC operates as an MSSP, you may be communicating with dozens of customers every day. As an L2 analyst, one of the most frequent and important tasks you have is reporting security threats to the customers. This should always be done through an official channel, typically email, with SOC colleagues and customer representatives in copy, so there is a clear and shared record of every communication. Let's imagine a scenario from an OpenDoor customer:

1. The Scenario

The L1 analyst escalates a critical alert to you about a data stealer on LPT-007 You investigate the alert deeper and find out the affected developer, bob.phisher You confirm the impact of the incident: the stored AWS access keys have been stolen You remediate the malware and isolate the laptop, but can't "unsteal" the AWS keys You urgently contact the customer and explain how to invalidate the stolen AWS keys 2. The Initial Report

Your immediate task is to start the response within the SLA. For this, you collect what you know so far and send a report to the customer. At this stage, the report doesn't need to explain the whole incident, but must highlight the urgency of the incident, explain what the customer must do to stop it, and when to expect more updates from your team. The goal of the initial report is to start threat containment as soon as possible. See the email example below:

✉ The Initial Report Email Flowchart showing 4 steps: Highlight the urgency, Summarize the case, Suggest customer actions, Explain your next steps. 3. The Final Report

After the initial report, communication becomes ongoing: you share deeper findings, while the customer provides additional context from their side. Once all information has been gathered, you prepare a final report. The goal of the final report is to act as a formal proof that your work on the incident is over, and answer all questions the customer may have, such as how the attack started or why your SOC missed the threat. See the email example below:

✉ The Final Report Email Flowchart of 7 questions a final report must answer: How did the attack start, Who or what was affected, Is the attack still ongoing, What is the known impact, Why your SOC missed it, What will SOC do next, How to prevent reinfection. Challenge

View Site Open the website above, review this executive report, and correct what's not right for the target audience by clicking on the highlighted parts. Once you're done, receive the flag for Question 3. For a better experience on small screens, consider opening the website in full-screen mode.

Static site image.

Answer the questions below

Should you complete the analysis after sharing the initial SOC report? (Yea/Nay) Yea

Correct Answer Should you keep your team informed about the ongoing communication? (Yea/Nay) Yea

What flag did you receive after completing the task's challenge?

• Missing recipient - the emails

  • Your SOC team should always be informed about the incident thread.

• missing context - a login

  • It doesn’t say what service or system was logged into. VPN? M365 portal?

• Perform data wipe of the Tim Balmer’s laptop (SN: X12157690)

  • The response is too harsh and unnecessary for what’s known right now.

• Don’t ignore this email

  • unprofessional language

    • the text sounds unprofessional and even rude in some contexts

• once we finalize it

  • unclear timeline

    • you should aim to set real expectations: 30 minutes, 2 hours, end of day

SOC/DFIR Communication

SOC and DFIR Relationship

The Digital Forensics and Incident Response (DFIR) team is like a fire department. Whenever a major incident happens, and regular logs aren't enough, they join the efforts and often take the incident ownership over SOC analysts. In smaller companies, SOC and DFIR teams are typically a single entity, and the communication is simple and casual. In bigger ones, they are independent, and the communication becomes more formal. Let's imagine a scenario:

1. Your MSSP has just started the onboarding and covers 10% of OpenDoor's AD network

2. You received a critical Ransomware Infection alert from the monitored part of the network

3. The evidence leads you to the conclusion that the whole AD network is being encrypted

4. You isolate what you can, call the customer, and suggest shutting down all their servers

5. OpenDoor urgently hires a DFIR team from TrySaveMe to take over the critical incident

6. You are asked to hand over all findings and indicators you found in SIEM to TrySaveMe

DFIR Handover Notes

Unlike C-level leadership and MSSP customers, DFIR team members focus less on style and language, but more on raw facts and evidence. They would expect actionable TTPs and attack artifacts from you so that they could start where you ended; one page of your SIEM findings would be more valuable than ten pages of filler text. In our example, TrySaveMe would be interested in:

• Incident Context: How everything started and what log sources your SOC monitors

• Attack Timeline: When and where the attack started, and how it continued step by step

• Attack Scope: All you know about the affected hosts, users, and other related assets

• Performed Actions: What response actions have you or the customer already done

• Raw Indicators: IPs, domains, hashes, scripts, tools, and other IoCs you identified

Handover Notes Example

Internal notes are often shared on a voice call or through an informal chat channel. However, in our scenario, TrySaveMe is an external DFIR team, so you'd better communicate via email for accountability and legal purposes. Also, keep in mind that DFIR teams rarely need generic recommendations; they are experts and just need the findings and facts. Below is an example of handover notes you can prepare:

✉ DFIR Handover Notes: OpenDoor Inc.

To: dfir@trysaveme.thm, soc@tryhackme.thm

Subject: [Handover Notes] Ransomware Attack on OpenDoor Inc.

Case Summary

OpenDoor Inc. is actively experiencing a ransomware attack targeting their Active Directory environment. SOC visibility covers 10% of the environment, where ransomware deployment was prevented. The remaining 90% of the environment is presumed encrypted. The customer has been notified, and the data center has been fully shut down as a containment measure. Incident timeline and reference links below:

• [Customer's wiki page with AD network diagrams and subnet ranges]

• [Document with monitored servers; SIEM, EDR, and other tools in use]

• [Links to the received SOC alerts (e.g., in SIEM or a ticketing platform)]

Mar 6, 07:15 UTC | WEB-01
Automated HTTP recon originating from 204.17.98.56 targeting portal.opendoor.thm, a corporate website hosted on WEB-01, an AD-joined IIS server at London HQ (10.0.0.5). The IIS process was running under NT AUTHORITY\SYSTEM.

Mar 6, 07:32 UTC | WEB-01
Attacker exploited an unrestricted file upload vulnerability in /feedback/form.php on the website to upload a PHP web shell (shell.php) via HTTP POST. The web shell was used to execute discovery commands (whoami, ipconfig, systeminfo) and drop an unidentified C2 binary (beacon.exe) to C:\Windows\.

Mar 6, 07:45 UTC | WEB-01
The C2 binary was persisted via a scheduled task named \TelemetryService, created using schtasks.exe. The beacon.exe beacons to 211.19.12.34:8080 every minute. No further malicious activity was observed within, but note that our monitoring breadth and depth are very limited.

Mar 6, 08:22 UTC | INT-FS-02
Critical EDR alert triggered on INT-FS-02 (Windows file server, 10.0.0.82, same subnet as WEB-01) for C:\gaze.exe, identified as Medusa ransomware. The binary was delivered via WMI from 10.0.0.96 (unknown host) using domain Administrator credentials. Full command: wmic /node:INT-FS-02 /user:CORP\Administrator /password:Welcome! process call create "cmd.exe /c C:\gaze.exe". EDR successfully blocked execution.

SOC Response
Upon triage of the INT-FS-02 alert, SOC assumed that WMI ransomware deployment was likely in progress across all customer hosts. All monitored endpoints, including WEB-01 and INT-FS-02, were isolated. The customer was contacted by phone; they confirmed that some servers were already unresponsive. According to our recommendations, the customer shut down the entire HQ data center to stop ransomware deployment.

Indicators

• Web shell file: shell.php

• Web shell user (IP): 204.17.98.56

• C2 file: C:\Windows\beacon.exe

• C2 MD5: ed1bb069b0bd52698b8c9ae9a397b343

• C2 persistence (task): \TelemetryService

• C2 IP: 211.19.12.34:8080

• Ransomware file: C:\gaze.exe

• Ransomware MD5: 5dacf83e155e11b0cf721dd9c60646d3

• Ransomware origin host: 10.0.0.96

Challenge

View Site

Open the website above, review the handover notes to the DFIR team, and correct any mistakes you find by clicking on the highlighted parts. Once you're done, receive the flag for Question 3. For a better experience on small screens, consider opening the website in full-screen mode.

Answer the questions below

Are L2 handover notes meant for a non-technical audience? (Yea/Nay) Nay

What part of the handover notes lists your findings chronologically? Attack Timeline

What flag did you receive after completing the task's challenge?

• unnecessary text:

2 - ambiguous phrasing

missing actor - was executed

was exfiltrated - no eveidence

other IPS - missing context

Responsible AI Usage

AI in SOC Report Writing Think about how much time you'd need to write reports similar to those in the previous tasks. Even if you already have the attack chain in your head, translating it to a formal report might take half an hour, or even more if English is not your native language. This is where GenAI can help: you feed your notes and report requirements to a prompt, and receive a well-structured report in the output.

Importance of Case Context

The quality of an AI-assisted report depends on the LLM model and context you provide. Ideally, your prompt should fit into the model's context window, include your requirements for report style and size, and contain the following context:

Customer profile: Industry, size, unique MSSP contract agreements Asset details: Role of the server or position of the affected employee Threat intelligence: Enriched TI reports about the observed indicators Historical context: Summaries and outcomes of past similar incidents Monitoring notes: Interesting False Positives cases or SIEM specifics AI is only as good as what you feed it. Experiment and find your "golden prompts". Responsible AI Usage While GenAI does a great job at summarizing the incident and setting the right style for the audience, its results must always be verified, especially if the report is sent outside of your team. The customers won't care if you used AI or not, but it is fully your responsibility to send a correct, professional report. The main pitfalls you can have with using AI-assisted reports are:

1. Sensitive Data Exposure

First of all, don't forget that all data you paste on the Internet becomes out of your control, and GenAI prompts are no exception. If your team uses cloud GenAI services instead of relying on self-hosted models, you must ensure that the confidential data is not pasted into prompts, especially the data of your MSSP customers and hardcoded credentials (e.g., in the process command line).

1. Too Much Filler Text

GenAI excels at generating text, but the report readers need not just any text but actionable instructions. A customer might scroll through 10 pages of the report and still not find any attack indicators or applicable recommendations. That's an indicator of a bad report. Your primary task is to keep the report structured and actionable - not big and complex.

1. GenAI Hallucinations

Imagine your company uses a security tool that reads password hashes of domain users and checks if they are found in public data leaks. If you feed the behavior of the tool to the AI, it will surely panic, alert on credential dumping malware, and recommend isolating the host. To avoid such scenarios, you should provide enough context, including the tool documentation.

1. Destructive Containment

I once had a security incident, where attackers injected malware code into Windows Explorer's memory and the AI assistant recommended quarantining the explorer.exe binary. At first, it sounds correct: a binary did malicious action, so let's block it. However, since Explorer is a core OS component, such action will completely break the system and still not remediate the threat. Be very careful with trusting AI regarding containment and eradication.

Answer the questions below

What should you provide in the AI prompt to get the best reports? Context

Should you fully rely on GenAI for critical decision making? (Yea/Nay) Nay

Conclusion

Communication becomes more critical as you move up to L2 and beyond. Even if you are a security expert, the employees and customers you protect can't act without clear, simple guidance from you. Don't underestimate report writing, as it is a core skill for L2 and further leadership roles. Also, if you plan to take the SAL2 exam, check out the section below. Either way, we hope you enjoyed the room!

SAL2 Exam Tips

Real-world external communication is often chaotic: you miss details and send follow-ups, customer misunderstands your suggestions and asks for a call, DFIR team doesn't wait for your notes and starts independently. The SAL2 exam does not account for these edge cases and expects one clean report, written once, after reviewing the incident. That means a few special rules apply:

• Fully investigate the threat first and then start writing the report (no follow-ups)

• Merge the initial and final reports into one complete email for a C-level audience

• Analyse all logs available before sharing handover notes with the DFIR team