Post cover image

September 7, 2026

From Alert to Investigation: My Hands-On SOC Phishing Investigation

When learning cybersecurity, it is easy to spend a lot of time learning individual tools and commands.

By Cybersage

4 min read

But working as a SOC analyst requires something more:

You need to know what to do when an alert actually appears.

That was the main reason I worked through this hands-on SOC investigation.

The exercise simulated a corporate environment experiencing a phishing-related security scenario called:

Phishing Unfolding

Instead of simply reading about phishing or SOC alert triage, I worked through the alert lifecycle myself — from the alert queue to investigation, classification, documentation, and case reporting.

What Was the Goal?

The goal was simple:

Investigate security alerts and determine what deserves attention.

The simulated environment contained six alerts involving two major categories:

  • Phishing
  • Suspicious process activity

The dashboard initially showed:

6 Alerts
0 Closed
0 True Positive
0 False Positive

This gave me a clean starting point.

None None None

The important part was that I wasn't supposed to blindly close alerts.

I had to investigate them first.

Understanding the SOC Alert Lifecycle

Before starting the investigation, I thought about the process as:

Alert
 ↓
Triage
 ↓
Investigate
 ↓
Classify
 ↓
Document
 ↓
Close
 ↓
Case Report

This simple workflow helped me understand how a SOC analyst approaches security events.

Step 1 — Looking at the Alert Queue

The first place I went was the alert queue.

There were six alerts:

  • Suspicious email from external domain
  • Suspicious attachment found in email
  • Suspicious parent-child relationship

All of them were currently waiting for analyst action.

This immediately reminded me of one of the challenges SOC teams face:

Not every alert deserves the same level of attention.

An analyst needs to quickly understand what each alert represents and decide how deeply it should be investigated.

Step 2 — Investigating a Suspicious Email

I opened alert 1000.

The detection was:

Suspicious email from external domain.

The underlying evidence was much more interesting than the alert title.

The email contained an unusual inheritance story and requested banking information.

The sender was:

eileen@trendymillinercy.com

and the recipient was:

support@tryhatme.com

There was no attachment.

The message was inbound.

At this point, I started looking for phishing indicators.

Step 3 — Thinking Like an Analyst

Rather than immediately saying:

"This is phishing."

I broke the email down.

Sender

Is the sender expected?

Domain

Does the sender domain appear trustworthy?

Subject

Does the subject make sense?

Content

Is the message trying to create urgency or emotional pressure?

Requested information

Is the sender asking for sensitive information?

The request for banking information was particularly concerning.

This is an example of why alert triage requires analysis rather than simply trusting the detection rule.

Step 4 — True Positive or False Positive?

The platform then asked me to make an important decision:

True Positive
        or
False Positive?

This is one of the most important concepts in SOC operations.

A True Positive means the security detection correctly identified suspicious or malicious activity.

A False Positive means the detection fired, but investigation determined the activity was legitimate.

The classification should always be supported by evidence.

A Lesson About Investigation Notes

The platform also required a closure rationale.

This is something I initially underestimated.

It is not enough to write:

"False positive."

A professional investigation note should explain:

When did it happen?
Who was involved?
What happened?
What evidence was reviewed?
Why was the alert classified this way?

This makes the investigation useful to other analysts and creates an audit trail.

Step 5 — Looking at Endpoint Activity

The scenario wasn't limited to email.

There were also Sysmon process alerts.

One event showed:

powershell.exe
       ↓
net.exe

with the command:

net.exe localgroup

Another process event involved:

powershell.exe
       ↓
whoami.exe

At first, this looks suspicious.

Why?

Because commands such as whoami and net can be used to discover information about a Windows system.

But there is an important lesson here:

Suspicious does not automatically mean malicious.

These commands can also be used legitimately by administrators and troubleshooting tools.

So the next question should be:

What context surrounds the process?

Parent-Child Relationships Matter

Instead of simply seeing:

net.exe

I now had:

powershell.exe
       ↓
net.exe

That relationship gives the analyst more context.

This is why endpoint telemetry is so valuable.

A single process may look harmless.

Its execution chain may tell a different story.

Step 6 — Closing and Reporting

Once an alert had been investigated and classified, it could be closed.

The resolved alert then appeared under Case Reports.

This provides an investigation history that can be reviewed later.

A SOC investigation therefore isn't just:

Find alert → close alert

It is:

Find
 ↓
Understand
 ↓
Investigate
 ↓
Classify
 ↓
Explain
 ↓
Document
 ↓
Resolve

What Did I Actually Learn?

This exercise taught me several practical lessons.

1. Alert triage is a skill

A SOC analyst may see many alerts during a shift.

The ability to quickly determine what deserves attention is critical.

2. Evidence matters more than alert titles

A detection rule tells you:

"Something looks suspicious."

Your job is to determine why.

3. Context is everything

A suspicious PowerShell process might be malicious — or it might be legitimate administration.

The surrounding activity matters.

4. Documentation matters

Another analyst should be able to read your investigation notes and understand how you reached your conclusion.

5. False positives are part of SOC work

Detection rules are not perfect.

Good SOC teams continuously tune detections to reduce unnecessary alerts while maintaining useful coverage.

The Bigger Picture

This exercise helped me understand where different cybersecurity technologies fit together.

               Security Events
                       ↓
        ┌──────────────┴──────────────┐
        ↓                             ↓
      Email                         Sysmon
        ↓                             ↓
        └──────────────┬──────────────┘
                       ↓
                  Detection
                       ↓
                  SOC Alert
                       ↓
                 Alert Triage
                       ↓
                  Investigation
                       ↓
             ┌─────────┴─────────┐
             ↓                   ↓
        True Positive       False Positive
             ↓                   ↓
       Escalate/Case          Document
             └─────────┬─────────┘
                       ↓
                    Resolve

This is the kind of workflow I want to become comfortable with as I continue developing my SOC and blue-team skills.

Final Thoughts

The biggest takeaway from this lab wasn't a particular button or feature.

It was learning to think like an analyst.

Instead of asking:

"What does this alert say?"

I learned to ask:

"What evidence caused this alert, does the activity make sense, and what should I do next?"

That change in mindset is one of the most valuable things I have taken from this exercise.

I'm continuing to build my cybersecurity skills through practical labs, focusing not only on tools but also on the investigation process behind them.

Skills Practiced

SOC Operations • Alert Triage • Phishing Analysis • SIEM • Sysmon • Incident Investigation • TP/FP Classification • Case Management • Security Monitoring • Incident Documentation

#CyberSecurity #SOC #SOCAnalyst #BlueTeam #SIEM #Phishing #IncidentResponse #CyberSecurityLearning #Sysmon #SecurityOperations #HandsOnLearning