Agent Foskett • Microsoft Security • Operational Visibility

Misconfigurations That Passed Health Checks But Failed Reality

Microsoft Defender was deployed. Microsoft Sentinel was collecting logs. MFA was enabled. Conditional Access policies existed. Secure Score looked healthy.

On paper, everything looked secure.

But during investigation, the environment told a different story. This Agent Foskett briefing looks at the quiet cracks that survive inside apparently healthy Microsoft environments — exclusions, assumptions, configuration drift, incomplete telemetry and security settings that slowly move away from operational reality.

Agent Foskett Microsoft security misconfiguration and configuration drift investigation
Briefing summary

Healthy dashboards do not always mean operational security. GEMXIT looks beneath the green ticks to find the exclusions, telemetry gaps and configuration drift that attackers can use before anyone notices.

Hunt configuration drift
Review exclusions and blind spots
Validate operational visibility
🚨 The dashboard was green. The exposure was still there.
A health check can confirm that controls exist. It does not always prove that the organisation can detect, interpret and respond to what is happening inside the environment.
Book a security review →

What we actually found

The environment was not obviously broken. That is what made the exposure dangerous. The gaps were small, familiar and easy to overlook.
Conditional Access exclusions Temporary exclusions that were created for support, migrations or testing quietly survived long after their original purpose disappeared.
Incomplete telemetry Some devices, users, workloads and mail signals were only partially visible, making the environment look healthier than it really was.
DMARC configured, but not enforced Email authentication appeared to exist, yet spoofed or failed authentication signals could still reach users depending on policy, handling and delivery action.
Long-lived sessions MFA was enabled, but session persistence and token behaviour still needed review against real operational risk.
Alert suppression Some noisy signals had been tuned down so aggressively that meaningful activity could blend into normal operations.
Behaviour nobody questioned The most useful signals were not always critical alerts. They were behaviours that simply did not make sense when viewed in context.

The dangerous illusion of configured

One of the biggest misconceptions in Microsoft security environments is the belief that deployed controls automatically equal operational protection.
Policy existence is not enforcement A Conditional Access policy can exist but still miss important users, apps, platforms, locations or device states.
Visibility is not interpretation Sentinel can ingest logs and Defender can record events, but somebody still needs to connect the weak signals together.
Compliance is not resilience Secure Score and recommendations help guide improvement, but they are not a substitute for real-world investigation and testing.

First hunt: legacy authentication and risky client behaviour

Legacy or unexpected client application usage can expose identity risks that do not always appear obvious from a high-level health dashboard.
legacy-authentication-and-client-apps.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
SigninLogs
| where TimeGenerated > ago(14d)
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| project TimeGenerated, UserPrincipalName,
          IPAddress, AppDisplayName, ClientAppUsed,
          ConditionalAccessStatus, ResultType
| order by TimeGenerated desc
What to review Look at the user, app, IP address, client application and Conditional Access result. Ask whether that sign-in path should still exist.
Why it matters Older or unexpected authentication flows can undermine modern controls if they are not blocked, monitored or understood.
Best next pivot Compare findings with Conditional Access scope, authentication methods, risky users, sign-in risk and excluded groups.

Second hunt: DMARC failures that still reached users

Email authentication can appear configured while failed authentication signals still result in delivered or user-visible messages.
dmarc-failures-delivered.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
EmailEvents
| where Timestamp > ago(14d)
| where AuthenticationDetails has "dmarc=fail"
| where DeliveryAction !in ("Blocked", "Quarantined")
| project Timestamp, SenderFromAddress,
          SenderMailFromAddress, RecipientEmailAddress,
          Subject, DeliveryAction, AuthenticationDetails
| order by Timestamp desc
What to review Check whether authentication failed, whether the sender was spoofed, and whether the message was still delivered, junked or user-visible.
Why it matters DMARC visibility is useful only if policy, handling and investigation processes are aligned with actual delivery behaviour.
Best next pivot Pivot into URL clicks, mailbox rules, user reports, sender domains and related message campaigns.

Third hunt: after-hours activity hiding inside normal operations

Not every risky action is malware. Sometimes the strongest signal is legitimate activity happening at a time, volume or pattern that does not fit the user.
after-hours-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
AuditLogs
| where TimeGenerated > ago(14d)
| where Operation has_any ("FileDownloaded", "FileAccessed")
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 6 or Hour > 20
| project TimeGenerated, Operation, UserId, IPAddress
| order by TimeGenerated desc

Fourth hunt: Defender visibility gaps

Defender may be deployed, but coverage still needs to be validated. Missing, stale or unhealthy devices can create blind spots that attackers do not need to defeat — only avoid.
defender-device-visibility.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
DeviceInfo
| summarize LastSeen = max(Timestamp) by DeviceName, OSPlatform, OnboardingStatus
| extend DaysSinceSeen = datetime_diff("day", now(), LastSeen)
| where DaysSinceSeen > 7 or OnboardingStatus != "Onboarded"
| order by DaysSinceSeen desc

How GEMXIT approaches Microsoft security reviews

At GEMXIT, we do not simply check whether features are enabled. We investigate whether the environment is actually visible, understood and defensible.
We question assumptions What was excluded? What was ignored? What was configured years ago and never reviewed again?
We validate telemetry Security reviews need to confirm what the organisation can actually see when an incident or near-miss occurs.
We hunt behaviour Meaningful investigations rarely begin with a single perfect alert. They often begin with weak signals that only become clear when correlated.
The environment passed the health check. The attacker passed through it.
That is why investigation-led Microsoft security reviews matter. Dashboards show configuration. Investigations reveal reality.
Contact GEMXIT

Final thought

The best security teams do not trust green dashboards blindly. They ask what the telemetry says when reality tests the environment.
At GEMXIT We use Microsoft Defender XDR, Sentinel and KQL to hunt beyond the obvious, validate weak signals and improve practical security visibility.
Agent Foskett mindset The important question is not only “Did the dashboard look healthy?” It is “What does the telemetry reveal when we investigate properly?”

Continue the investigation with the KQL Threat Hunting Guide, Microsoft Defender KQL Guide and Microsoft Security Operations.

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

Microsoft Security Misconfigurations and Configuration Drift

This Agent Foskett briefing explains how Microsoft security environments can pass health checks while still carrying operational exposure caused by exclusions, incomplete telemetry, legacy settings and configuration drift.

Defender XDR, Sentinel and KQL Security Review

GEMXIT uses Microsoft Defender XDR, Microsoft Sentinel and KQL to investigate weak signals, validate security visibility and uncover operational blind spots that dashboards may not reveal.

Conditional Access, DMARC and Microsoft 365 Investigation

Example investigation areas include Conditional Access exclusions, legacy authentication, DMARC failures, after-hours downloads, endpoint onboarding gaps and suspicious behaviour that does not always generate a critical alert.