Agent Foskett • Microsoft Defender XDR • KQL Threat Hunting

The Dashboard Was Green

No high-severity incident.

No ransomware banner. No critical Defender alert. No urgent Sentinel case waiting in the queue.

The dashboard looked healthy.

But the telemetry told a different story.

A sign-in happened outside the usual pattern. A mailbox event did not quite fit. A PowerShell command ran without creating a major alert. A SharePoint download occurred at a strange time. An email authentication result looked weak, but the message was still delivered.

This Agent Foskett briefing looks at one of the most important lessons in Microsoft security operations: do not just wait for alerts — ask the data better questions.

Discuss your environment Back to briefings

Agent Foskett Microsoft Defender XDR telemetry investigation

Briefing summary

Microsoft Defender XDR is powerful, but dashboards and automated alerts are not the whole investigation. GEMXIT looks at how KQL, identity telemetry, email signals, endpoint events and behavioural patterns help reveal what dashboards can miss.

Investigate beyond severity scores

Ask better KQL questions

Correlate identity, email and endpoint telemetry

What happened

The environment looked normal because nothing obvious was screaming for attention. But several weak signals were already present across identity, email, endpoint and cloud activity.

The dashboard looked healthy No urgent incident was raised. No red banner appeared. Nobody felt immediate pressure to investigate because the surface view looked clean.

The signals were scattered One sign-in looked unusual. One email had weak authentication. One process execution seemed odd. Each signal alone looked easy to dismiss.

The pattern mattered The risk became clearer only when the data was correlated across users, devices, applications, locations and timing.

The problem with alert-only security

Alerts are important, but they are not the same as understanding. Attackers often succeed by staying just below the threshold where tools become noisy.

Severity is not context A low-severity or informational signal can still matter when it appears beside suspicious identity, email or endpoint behaviour.

Allowed does not mean safe A user may be allowed to sign in, download files, run scripts or access email. The investigation asks whether the behaviour makes sense.

Timing tells stories After-hours access, unusual sequence, impossible travel, rare process execution and sudden data movement often reveal what the dashboard does not.

First hunt: unusual successful sign-ins

A successful sign-in is not always a safe sign-in. Start by looking for successful access that does not match normal user behaviour.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize SignInCount = count(),
            Apps = make_set(AppDisplayName),
            IPs = make_set(IPAddress),
            Locations = make_set(Location),
            Clients = make_set(ClientAppUsed)
            by UserPrincipalName, bin(TimeGenerated, 1d)
| order by SignInCount desc

What to review Look for users with unusual IP spread, unexpected locations, unfamiliar client apps or sudden changes in successful sign-in volume.

Why it matters Compromised sessions and suspicious access may still appear as successful authentication events rather than blocked attempts.

Best next pivot Pivot into Conditional Access results, device details, MFA claims, session age, token behaviour and impossible travel patterns.

Second hunt: suspicious email signals without panic

Email telemetry often contains weak indicators that are easy to ignore until they appear alongside identity or click activity.

EmailEvents
| where Timestamp > ago(7d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail")
   or ThreatTypes has_any ("Phish", "Spoof")
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          AuthenticationDetails,
          ThreatTypes
| order by Timestamp desc

What to review Check whether failed authentication, spoof indicators or suspicious threat types still resulted in delivery to the mailbox.

Why it matters Email risk often becomes meaningful when combined with user clicks, unusual sign-ins or identity changes after delivery.

Best next pivot Pivot into UrlClickEvents, mailbox rules, sign-in logs, user risk, inbox forwarding and suspicious application consent.

Third hunt: endpoint behaviour that did not become a major alert

Endpoint telemetry can reveal scripts, command-line activity and living-off-the-land behaviour that may not immediately become high-severity incidents.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "mshta.exe", "rundll32.exe")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp desc

What to review Look for strange command lines, encoded commands, script hosts, unexpected parent processes and activity that does not match the user role.

Why it matters Attackers often use legitimate Windows tools because they blend into normal administrative noise and may not trigger obvious malware detection.

Best next pivot Pivot into network events, file creation, scheduled tasks, registry changes, user sign-ins and any related Defender incidents.

The questions good investigators ask

The goal is not to create panic. The goal is to build better security intuition by asking practical questions before weak signals become serious incidents.

Does this behaviour fit the user? Role, timing, device, location, application and volume all matter when deciding whether activity is normal or suspicious.

What changed recently? New devices, new IPs, new mailbox rules, new applications, new permissions or new patterns can be more revealing than a single alert.

What else happened nearby? A suspicious email, a user click, a new sign-in, a PowerShell event and a file download may become meaningful only when viewed together.

Is the control actually enforcing? MFA, Conditional Access, DMARC, device compliance and Defender policies should be validated by evidence, not assumed from configuration alone.

Was access allowed for the right reason? Successful access is not the end of the investigation. It is often the beginning of understanding trust, sessions and risk.

Would we notice this tomorrow? If the same activity happened again, would the organisation detect it, understand it and respond with confidence?

How GEMXIT approaches Defender investigations

At GEMXIT, we do not treat Microsoft Defender XDR as a magic box. We use it as a source of evidence that needs context, questions and investigation discipline.

We investigate telemetry EmailEvents, UrlClickEvents, DeviceProcessEvents, SigninLogs and audit records all help build the story behind the event.

We correlate weak signals One event may be harmless. Several weak signals across identity, endpoint and email telemetry can tell a much stronger story.

We improve practical visibility The goal is not to chase noise. The goal is to help organisations understand what their Microsoft environment is already trying to tell them.

Final thought

The dashboard was green. The environment looked quiet. But quiet does not always mean safe.

At GEMXIT We help organisations use Microsoft Defender XDR, Microsoft Sentinel, Entra ID and KQL to investigate beyond dashboards, validate weak signals and improve security visibility.

Agent Foskett mindset The important question is not only: “Did Defender create an alert?”

It is: “What does the telemetry reveal when we investigate properly?”

Continue the investigation with Cyber Security Is Not Just Antivirus, When Nothing Looks Wrong, The PowerShell Never Triggered An Alert, KQL Threat Hunting Guide, Microsoft Defender KQL Guide and Microsoft Security Operations.

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