Lesson 2 — The Alert Says “Suspicious” — What Does That Actually Mean?
You have selected the first alert from the queue. Now comes the next SOC mistake to avoid:
treating the alert title as the conclusion.
“Suspicious PowerShell activity.” “Unusual sign-in.” “Potential credential theft.”
Those phrases are detection claims. They tell you why a security product wants your attention.
They do not, by themselves, prove what happened.
The alert in front of you
Microsoft Defender has raised a high-severity alert for suspicious PowerShell activity on a finance laptop. Your job is to work out exactly what the detection says — and what it does not say.
Case briefing
Investigation objective
Learn how to read a security alert as an analyst. Identify the detection claim, triggering evidence, affected entities, timestamps and supporting signals before deciding whether the activity is malicious, benign or still unexplained.
Investigator's rule
Do not promote detection language into fact. “Suspicious” means the observed activity matched logic that deserves investigation. It does not automatically mean compromise occurred.
Stage 1 — translate the alert into plain English
Before pivoting anywhere, rewrite the alert in neutral language. Strip away words such as suspicious, malicious, anomalous and compromised until only the observable claim remains.
| Alert language | Neutral analyst translation |
|---|---|
| Suspicious PowerShell activity | PowerShell executed behaviour that matched this detection's suspicious criteria. |
| Impossible travel | Authentication events were observed from locations that appear inconsistent within the measured time window. |
| Potential credential theft | Activity associated with known credential-access techniques was observed. |
| Unusual sign-in | The sign-in differed from an established or expected pattern. |
Why neutral language matters
If you begin with “malware ran,” every later event risks being interpreted to support that theory. If you begin with “PowerShell executed an encoded command,” you can investigate what the command did without deciding the answer first.
The detection has a point of view
Every alert is produced by logic: analytics, behavioural models, threat intelligence, correlations or product detections. Understanding what triggered that logic helps you understand how much the alert actually tells you.
Stage 2 — separate the alert into six questions
Entities give you pivots
The user, device, IP address, process, URL, mailbox or cloud resource named in an alert are not decoration. They are the starting points for the next investigation steps.
Timestamps give you boundaries
The alert creation time may not be the same as the event time. Analysts need the timestamp of the underlying activity so they can examine what happened immediately before and after it.
Stage 3 — identify fact, interpretation and unknown
This is one of the most useful habits in SOC work. For every important statement, decide which of three buckets it belongs in.
| Category | Example from this alert | Analyst treatment |
|---|---|---|
| Fact | powershell.exe executed on Finance-LT-044. |
Supported directly by telemetry. |
| Fact | The command line contained encoded content. | Supported directly by the observed command line. |
| Interpretation | The encoded command was malicious. | Requires investigation. |
| Unknown | What process launched PowerShell? | Pivot to process telemetry. |
| Unknown | What did the encoded command actually do? | Decode or inspect safely and correlate behaviour. |
| Unknown | Did PowerShell create files or make network connections? | Check related endpoint telemetry. |
Encoded does not equal malicious
Attackers use encoded PowerShell, but administrators and legitimate software can too. Encoding increases investigative interest; it does not remove the need to examine the command and surrounding behaviour.
Suspicious does not equal false positive either
The opposite mistake is dismissing the alert because legitimate explanations exist. Your task is not to defend or condemn the activity. Your task is to determine which explanation the evidence supports.
Stage 4 — ask what evidence would change your mind
Good analysts do not merely collect more telemetry. They look for evidence that can discriminate between competing explanations.
Look for corroboration
A single suspicious command is one signal. A suspicious command followed by a dropped executable, outbound connection and persistence mechanism is a very different evidentiary picture.
Look for contradiction
Evidence can also weaken the malicious hypothesis. A known management process launching an approved signed script during a documented maintenance window may explain the detection.
Stage 5 — define the investigation before you query
Agent Foskett does not begin with a giant hunt across every table. The alert has already given us a focused set of questions.
Agent Foskett's alert-reading workflow
Your alert-reading evidence board
| Alert element | What to ask | Common mistake |
|---|---|---|
| Title | What is the detection claiming? | Treating the title as proven fact. |
| Severity | How strongly has the product prioritised it? | Assuming severity proves impact. |
| Description | What behaviour or logic triggered the alert? | Skipping directly to the entities. |
| Entities | What user, device, IP, process or resource can I pivot from? | Investigating the alert without expanding context. |
| Timestamp | When did the underlying activity occur? | Using alert creation time as the event time. |
| Evidence | Which observations are directly supported? | Mixing interpretation with telemetry. |
Write the initial assessment like an analyst
Example: Microsoft Defender generated a high-severity alert after PowerShell executed an encoded command on Finance-LT-044 in the context of alex.w. At this stage, telemetry confirms PowerShell execution and encoded command-line content, but the alert alone does not establish that the activity was malicious. Investigation should determine the parent process, command contents, subsequent file and network activity, related alerts and whether an approved administrative explanation exists before assigning a final disposition.
Lesson 2 key takeaways
- An alert title is a detection claim, not an investigation conclusion.
- Translate loaded alert language into neutral, observable behaviour.
- Identify what triggered the detection before chasing every related event.
- Extract the user, device, process, IP address, resource and event time as investigation pivots.
- Separate facts, interpretations and unknowns.
- “Suspicious,” “unusual” and “potential” all require validation.
- Look for evidence that can both support and contradict your working theory.
- Correlated behaviour is usually more informative than one isolated signal.
- Write investigation questions before writing a conclusion.
- The purpose of the investigation is to explain the activity — not to prove the alert correct.
Module 1 — inside the SOC
You now understand what the alert is actually claiming. The next challenge is deciding whether the severity assigned by the product should control your response.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 1: Inside the SOC: Thinking Like an Analyst
How to read a security alert in a SOC
Lesson 2 of the Agent Foskett SOC Analyst Academy teaches analysts how to understand security alert titles, descriptions, entities, timestamps and triggering evidence before beginning a deeper investigation.
Security alert investigation and evidence validation
Learn how to separate detection claims from facts, identify investigation unknowns, build evidence-driven questions and avoid treating words such as suspicious, unusual or potential as proof of malicious activity.
