Defender XDR • Sentinel • PowerShell

The Alert Wasn’t Understood

“Low confidence.” “Informational.” “No automated action.” It looked like nothing. But once the behaviour was investigated across process execution, outbound traffic and identity telemetry, the story changed completely.

This is where Microsoft security operations visibility becomes critical — not just reading the label on an alert, but understanding what the signal actually means.

Discuss your environment Back to briefings

Briefing summary

A single Defender XDR alert looked harmless on the surface. But once the behaviour was hunted instead of dismissed, it exposed a chain across PowerShell, outbound communication, identity activity and time correlation.

Encoded PowerShell execution

Outbound traffic from same context

Unusual identity activity within minutes

What happened

No panic. No incident. Just one “informational” signal that deserved a second look.

The alert looked harmless Low confidence. Informational. No remediation. Exactly the kind of Defender XDR signal most teams acknowledge, close and move on from.

The clue that mattered The PowerShell activity was running in user context, using an encoded command. That is not the kind of behaviour you dismiss just because the severity label is soft.

The real shift The investigation stopped focusing on the alert and started focusing on the behaviour. That is where context began to emerge.

The pivot that changed everything

The alert alone was not enough. The real story only appeared when PowerShell execution, network activity and identity telemetry were correlated together.

let SuspiciousPowerShell =
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine contains "-enc"
                            or ProcessCommandLine contains "FromBase64String"
                            or ProcessCommandLine contains "IEX"
| project
                            PS_Time = Timestamp,
                            DeviceName,
                            User = InitiatingProcessAccountName,
                            CommandLine = ProcessCommandLine;

let NetworkActivity =
DeviceNetworkEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| project
                            Net_Time = Timestamp,
                            DeviceName,
                            User = InitiatingProcessAccountName,
                            RemoteIP,
                            RemoteUrl,
                            RemotePort;

let IdentityActivity =
SigninLogs
| where ResultType == 0
| project
                            SignIn_Time = TimeGenerated,
                            User = UserPrincipalName,
                            IPAddress,
                            Location = strcat(tostring(LocationDetails.city), ", ", tostring(LocationDetails.countryOrRegion));

SuspiciousPowerShell
| join kind=leftouter NetworkActivity on DeviceName, User
| where Net_Time between (PS_Time .. PS_Time + 10m)
| join kind=leftouter IdentityActivity on User
| where SignIn_Time between (PS_Time - 15m .. PS_Time + 15m)
| project
                            PS_Time,
                            DeviceName,
                            User,
                            CommandLine,
                            RemoteIP,
                            RemoteUrl,
                            IPAddress,
                            Location,
                            SignIn_Time
| order by PS_Time desc

Execution telemetry Encoded PowerShell, obfuscated syntax and user-context execution gave the first clue that this was more than background noise.

Network correlation Outbound PowerShell traffic from the same device and user context shifted the event from suspicious execution to probable malicious behaviour.

Identity timing A successful sign-in near the execution window added the final layer of context, linking device behaviour to identity activity in a way no single alert had done.

Agent Foskett moment

Individually, the events looked benign. Together, they formed a suspicious chain.

No alert stitched it together No single rule created the full story. No incident was raised. No automated logic joined process, network, identity and timing into one narrative.

The gap This is the difference between alert-driven security and context-driven investigation. One waits for confidence scores. The other asks what the evidence means.

That is why stronger identity and access visibility matters so much.

The lesson Defender detects signals. Sentinel gives visibility. But neither replaces investigation, curiosity or experience.

What most teams miss They ask, “Did I get an alert?” instead of asking, “Did I understand what it meant?”

What changed the outcome The moment the investigation pivoted from severity to behaviour, the signal became much more than an informational alert.

Why it matters If you only trust the severity rating, quiet compromise can sit in plain sight while the evidence remains scattered across tools.

Final thought

If your security model stops at alerts, you are already missing part of the story.

At GEMXIT We do not just read alerts. We investigate them properly, correlate telemetry and work out what the evidence is really saying. If you want to improve how your environment handles this, see our Cyber Security services.

Agent Foskett mindset Do not just trust the label. Hunt the behaviour. Follow the pivots. Check the timing. Understand the context.

If your Microsoft security stack is collecting signals but not surfacing real meaning, the next step is improving visibility and interpretation. 👉 Strengthen Azure security visibility and detection

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD

The Alert Wasn’t Understood

Briefing summary

What happened

The pivot that changed everything

Agent Foskett moment

Final thought

Microsoft Defender XDR Informational PowerShell Alert Investigation

Threat Hunting Across Process, Network and Identity Telemetry

Why Low Severity Alerts Still Matter