The Modern SOC Logic From Methodology To Granular Tooling
Mapping appropriate security tools to resolve investigations based on attack indicators
CYBERSECURITY
The Modern SOC Logic From Methodology To Granular Tooling
Mapping appropriate security tools to resolve investigations based on attack indicators
Image by Swimlane.
One of the biggest mistakes newcomers make in cybersecurity is becoming obsessed with tools. They spend months collecting bookmarks, installing frameworks, and memorizing commands, yet struggle to answer a simple question: what problem are you trying to solve?
The problem is not a lack of tooling since modern security teams have more visibility than ever before. SIEMs collect logs from thousands of systems, EDR platforms monitor endpoints continuously, threat intelligence feeds enrich indicators automatically, cloud providers generate endless streams of telemetry etc.
Thus the challenge is less in obtaining data but understanding which questions need answering and where to find the evidence. This important distinction separates tool operators from investigators.
SOC analysts, threat hunters, incident responders, purple teamers and ethical hackers have far more in common than most people realize. Although they use different technologies and operate from different perspectives, they are all attempting to answer the same fundamental questions.
What exists? What changed? Is it malicious? What happened? Did it spread? Could we detect it? How do we improve?
These questions categorize tools by purpose. In fact, questions drive investigations and tools answer those questions. The tools merely change depending on the environment and the nature of the investigation.
Consider investigating a phishing incident and what are the methodology and the selected tools from the start until the end.
How a SOC Analyst Investigates a Phishing Attack
Most phishing investigations fail because analysts jump directly into tools instead of following a structured methodology.
A mature investigation is not driven by VirusTotal, Defender, CrowdStrike, or any particular product but by questions. Each question leads to telemetry, telemetry leads to evidence and evidence drives decisions.
The objective is thus not to collect indicators but to determine what happened, whether the threat is real, how far it spread and whether the organization could detect it.
Example of Phishing Investigation Logic : Questions -> Telemetry source(s) -> Tool(s) -> Evidence -> Decision(s)
Phase 1: Initial Alert
Everything generally begins with a suspicious email. It could also be smishing, vishing, quishing, spoofing or other attack methods.
A user reports a phishing message, a mailbox rule triggers an alert or the email security gateway (SEG) flags a potentially malicious sender.
The first priority is preserving evidence and understanding the scope of delivery.
Tools to achieve email alerting and for preserving the logs? Email telemetry tools? There are multiple cloud-hosted SaaS platforms or even on-premise/self-hosted open-source options (Proxmox or Mailcow).
User reports suspicious email
│
▼
Preserve evidence
│
▼
Email telemetryAt this stage, analysts pivot into email logs to answer a simple question:
Was this email delivered only to one user, or was it delivered across the organization?
Examples of SaaS platforms for CSIRT and immutable email storage:
- Splunk Cloud: Best for advanced security investigations, tracking phishing, and correlating email logs with global company data. Splunk Attack Analyzer automatically detects and analyzes complex credential phishing and malware threats with prebuilt dashboards. It can be plugged into an existing infrastructure to enhance unified security operations.
- Datadog Cloud SIEM: Ideal for monitoring mail server performance, traffic anomalies and real-time deliverability issues. From threats detection to incident response, Datadog can help detect and resolve phishing activities. For example, flag OAuth consent phishing attempts by adding detection rules for illicit consent grant attacks.
- Sumo Logic: Cloud-native platform excellent for processing massive volumes of SMTP tracking logs and automated alerting. Their App Catalog allows to connect to different Cloud vendors to collect logs (for instance, from Google Workspace, Alert Center, Gmail Phishing dashboard), monitor, identify and track.
Phase 2: Determine Exposure
The next step is understanding how widely the message was distributed.
Email telemetry
│
▼
Was email delivered internally?
│
┌────┴────┐
│ │
▼ ▼
No Yes
│ │
▼ ▼
Close Identify recipients
│
▼
Who opened or clicked?An email delivered to one employee represents an isolated event. An email delivered to hundreds of employees may represent an active campaign. Then the goal is no longer the email itself but is identifying potentially exposed users.
Example of Tools to analyse the scope ? G WKS Email Log Search/ audit
Phase 3: Analyze the Lure
Once exposed users are identified, attention shifts toward the phishing artifact itself. The investigation now focuses on URLs, attachments, domains, sender infrastructure and reputation.
Recipients
│
▼
URL or Attachment?
│
┌───┴────┐
│ │
▼ ▼
URL File
│ │
▼ ▼
Reputation Analysis
│
▼
Malicious?At this point, analysts are trying to answer:
- Is the sender infrastructure suspicious?
- Is the domain recently registered?
- Has the URL been observed in previous campaigns?
- Does the attachment match known malware families?
The investigation remains focused on intent rather than execution.
Phase 4: Confirm Execution
The most important question in a phishing investigation is not whether the email is malicious but whether anything executed.
Malicious Artifact
│
▼
Endpoint Investigation
│
▼
Did code execute?
│
┌────┴────┐
│ │
▼ ▼
No YesThis is the point where the investigation transitions from email security to endpoint security. Here, analysts begin reconstructing process execution chains.
winword.exe
│
▼
powershell.exe
│
▼
payload.exeOr they check whether the execution chain used another medium such as the web browser to deploy a malware.
browser.exe
│
▼
download.exe
│
▼
malware.exeSo the objective is to determine whether user interaction resulted in execution.
Tools to identify local host execution: Zeek, Velociraptor, Wireshark, Sysmon, CAPEv2 etc.
Phase 5: Identify Persistence
Execution alone does not necessarily mean compromise so the next question becomes:
Did the attacker establish persistence?
Execution
│
▼
Persistence?
│
┌──┴──┐
│ │
▼ ▼
No Yes
│
▼
Scheduled Tasks
Registry Keys
Services
Startup EntriesPersistence significantly changes the severity of the incident because it indicates that the attacker may survive reboots, maintain access or execute additional payloads later.
tools: Autoruns, KAPE, RegRipper, Velociraptor, Osquery, Sysmon, CAPEv2 Sandbox, Sparrow.ps1, Maester etc.
Phase 6: Identify External Communications
After execution and persistence are validated, investigators examine network activity.
Execution
│
▼
External Communication?
│
┌──┴──┐
│ │
▼ ▼
No Yes
│
▼
DNS Activity
Proxy Logs
Firewall Logs
Network TelemetryThe objective is to determine whether the compromised host contacted command-and-control (C2) infrastructure, downloaded secondary payloads or exfiltrated data. At this stage, isolated phishing becomes a broader compromise investigation.
Tools: Zeek, Wireshark, Suricata, Brim, TCPDump, Osquery, Sysmon, Velociraptor, Netflow etc.
Phase 7: Determine Scope
One compromised workstation is rarely the entire story. This is why SOC analysts pivot from the affected host to the wider environment.
Compromised Host
│
▼
Environment Hunt
│
▼
Same Sender?
Same URL?
Same Hash?
Same Process Chain?
│
▼
Define Blast RadiusThe purpose is to answer:
- Are additional users affected?
- Are additional hosts compromised?
- Is this part of a larger campaign?
Only after this scope is understood can containment decisions be made confidently.
Tools: OpenSearch, Splunk, Velociraptor, KAPE, Osquery, BloodHound, Microsoft Entra ID Logs, Graylog, Shuffle etc.
Phase 8: Containment and Recovery
Once the blast radius is clear, containment begins.
Blast Radius
│
▼
Containment
│
▼
Host Isolation
Credential Reset
IOC Blocking
Email PurgeAt this stage, the priority shifts from investigation to risk reduction.
Tools: Ansible, Velociraptor, Shuffle, Openfirewall, CrowdStrike CRT, CyberArk, Veeam, Clonezilla, Restic etc.
Phase 9: Detection Validation
The final phase is often the most neglected. The incident is over, but the learning has only begun.
Incident
│
▼
Detection Review
│
▼
Could We Detect This?
│
▼
Improve CoverageEvery phishing investigation should conclude with a Purple Team question:
If this attack happened again tomorrow, would we detect it faster?
That question ultimately determines whether the organization becomes more resilient after the incident.
Tools such as Atomic Red Team, MITRE Caldera and Vector assist in this process. Also explore other security validation frameworks including MITRE ATT&CK Navigator and Stratus Red Team.
The Core Principle
A phishing investigation follows a sequence of investigative questions and resolves it with the help of a collection of tools. Therefore SOC analysts do not start with a dashboard. Instead, they build a hypothesis and follow the evidence wherever it leads.
Question
│
▼
Telemetry
│
▼
Evidence
│
▼
DecisionWas email delivered?
Email logs -> Message Trace / Google Workspace / Proofpoint / Mimecast -> Recipients, timestamps, delivery status -> Purge / monitor / expand scope
Was artifact malicious? URL, domain, IP, hash VirusTotal / URLScan / AbuseIPDB / GreyNoise / Any.Run Reputation, detections, infrastructure links Escalate / monitor
Did execution happen? Endpoint telemetry EDR / Sysmon / Windows Event Logs Parent-child process chain Contain / collect evidence / hunt
Did it spread? SIEM + EDR + DNS + email telemetry KQL / SPL / Sigma / Zeek Matching IOCs and behaviors Define blast radius …
Example of hypothesis approach: “If a user clicked this specific credential-harvesting link 15 minutes ago, there should be an outbound connection with a 200 OK status exists in our network data, followed closely by a login event from a foreign IP address."
To verify this specific link-and-credential-harvesting hypothesis, the SOC will need tools that track network connections and tools that audit identity authentication logs (e.g., Zeek, Suricata, Wireshark, TShark, Splunk Cloud, OpenSearch, Microsoft Entra ID Logs, Okta System Log, Sparrow.ps1).
The Investigation Logic Diagram
The following diagram illustrates the complete phishing investigation workflow from the initial report to containment and detection improvement.
┌─────────────────────────────────────────────┐
│ User reports suspicious email │
└──────────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Preserve evidence │
│ Original email, headers, attachments, URLs │
└──────────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Email Telemetry │
│ Message Trace / Email Logs │
└──────────────────┬──────────────────────────┘
│
▼ ┌───────────────────────────┐
│ Delivered to other users? │
└───────────┬───────────────┘
│
┌────────┴────────┐
│ │
No Yes
│ │
▼ ▼
Close Case Identify Recipients
│
▼
Who opened or clicked?
│
▼ ┌───────────────────────────┐
│ URL or Attachment? │
└───────────┬───────────────┘
│
┌───────┴───────┐
│ │
URL File
│ │
▼ ▼ Reputation Analysis Hash Analysis
Domain Analysis Sandbox Analysis
Infrastructure Malware Analysis └───────┬───────┘
│
▼ ┌───────────────────────────┐
│ Malicious? │
└───────────┬───────────────┘
│
┌────────┴────────┐
│ │
No Yes
│ │
▼ ▼
Monitor Endpoint Investigation
│
▼ ┌───────────────────────────┐
│ Did code execute? │
└───────────┬───────────────┘
│
┌────────┴────────┐
│ │
No Yes
│ │
▼ ▼
Monitor Process Tree Analysis │
▼ winword.exe
│
▼
powershell.exe
│
▼
payload.exe │
▼ ┌───────────────────────────┐
│ Persistence established? │
└───────────┬───────────────┘
│
┌────────┴────────┐
│ │
No Yes
│ │
▼ ▼
Continue Hunt Registry / Tasks
Services / Startup │
▼ ┌───────────────────────────┐
│ External communications? │
└───────────┬───────────────┘
│
┌────────┴────────┐
│ │
No Yes
│ │
▼ ▼
Continue Hunt DNS / Proxy
Firewall Logs
Network Telemetry │
▼ ┌───────────────────────────┐
│ Did it spread? │
└───────────┬───────────────┘
│
▼ Environment Hunt │
▼ Same Sender?
Same URL?
Same Hash?
Same Process Tree? │
▼ Define Blast Radius │
▼┌─────────────────────────────────────────────┐
│ Containment │
│ Host Isolation │
│ IOC Blocking │
│ Email Purge │
│ Credential Reset │
└──────────────────┬──────────────────────────┘
│
▼┌─────────────────────────────────────────────┐
│ Detection Review │
│ Could we detect this earlier? │
│ What telemetry was missing? │
│ What alerts should be improved? │
└──────────────────┬──────────────────────────┘
│
▼┌─────────────────────────────────────────────┐
│ Lessons Learned │
│ Better detections, controls and processes │
└─────────────────────────────────────────────┘In the end, the best SOC are selecting the right security tools to resolve critical questions based on tactical attack indicators. The SOC/CSIRT investigation is driven by questions at every steps with the same repetitive logic: Question → Telemetry → Evidence → Decision. The tools simply change depending on the telemetry available and the nature of the incident.
About me
I am a SecOps analyst in the FinTech insurance sector. My focus is on safeguarding sensitive assets by applying threat-informed defense strategies and ensuring strict adherence to industry standards (e.g., ISO 27001, ISO27701, NIST).
Sources
메타데이터
- post_id
- d41384b7a7e9
- slug
- the-modern-soc-logic-from-methodology-to-granular-tooling-d41384b7a7e9
- url
- https://medium.com/@mandem868/the-modern-soc-logic-from-methodology-to-granular-tooling-d41384b7a7e9
- canonical_url
- https://medium.com/@mandem868/the-modern-soc-logic-from-methodology-to-granular-tooling-d41384b7a7e9
- author_url
- https://medium.com/@mandem868
- status
- ok
- fetched_at
- 2026-06-14 11:28:49
