ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Sentinel • Analytics Rules • SentinelAudit • AzureActivity • Detection Engineering • KQL

Who Disabled the Sentinel Analytics Rule?

The SOC noticed something strange.

A detection that normally generated alerts had gone quiet.

The source data was still arriving.
The KQL still returned suspicious activity.

But Microsoft Sentinel was no longer creating alerts from the rule.

The analytics rule had been disabled.

When was it changed?
Who changed it?
What else did that identity modify?
And what happened while the detection was unavailable?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating a disabled Microsoft Sentinel analytics rule
The Attacks Hadn't Stopped. The Detection Had.

A quiet analytics rule can mean there is nothing to detect. It can also mean the detection itself changed.

✓ Confirm the rule state
✓ Reconstruct the change
✓ Hunt the detection gap

Silence was not evidence of safety

The first mistake would have been assuming that no new incidents meant the suspicious activity had stopped.

Agent Foskett checked the underlying data independently of the analytics rule.

Events were still arriving.
The hunting query still returned relevant activity.

The telemetry had not disappeared. The detection path had.

Confirm the current rule state

Microsoft Sentinel analytics rules are resources under Microsoft.SecurityInsights/alertRules, and their configuration includes whether the rule is enabled.

Agent Foskett preserved the affected rule's identifier, display name, workspace and current configuration.

Current state tells you what the rule looks like now. It does not tell you who changed it.

Start with Microsoft Sentinel's audit trail

Where SentinelAudit was available, Agent Foskett searched successful analytics-rule write and delete operations. A disable action changes rule configuration, so a write event is an important starting point.
sentinel-analytics-rule-audit.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
SentinelAudit
| where TimeGenerated > ago(30d)
| where OperationName in (
    "Microsoft.SecurityInsights/alertRules/Write",
    "Microsoft.SecurityInsights/alertRules/Delete"
)
| where Status == "Success"
| project TimeGenerated,
          OperationName,
          SentinelResourceName,
          SentinelResourceId,
          SentinelResourceType,
          SentinelResourceKind,
          ExtendedProperties,
          CorrelationId
| order by TimeGenerated desc

A write event did not automatically mean “disabled”

An analytics-rule write can represent different configuration changes.

The query could change.
The schedule could change.
The severity could change.
The rule could be enabled or disabled.

Agent Foskett inspected the audit details and correlated the event with the affected rule rather than treating every write as proof of disablement.

The operation identifies a change. The investigation still has to establish what changed.

Use AzureActivity to identify the control-plane actor

Microsoft Sentinel management activity can also be audited through AzureActivity. Agent Foskett filtered Microsoft.SecurityInsights operations and narrowed the results to the affected analytics-rule resource.
sentinel-rule-azureactivity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let RuleId = "00000000-0000-0000-0000-000000000000";
AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue startswith "MICROSOFT.SECURITYINSIGHTS"
| where ResourceId has RuleId
| project TimeGenerated,
          OperationNameValue,
          ActivityStatusValue,
          Caller,
          CallerIpAddress,
          ResourceId,
          CorrelationId,
          Properties
| order by TimeGenerated asc

Who changed the rule?

The control-plane evidence gave Agent Foskett the next pivot: the recorded caller.

It could be an administrator performing an approved change.
It could be an automation identity.
Or it could be a compromised privileged account.

Finding the caller establishes attribution to the recorded operation. It does not establish malicious intent.

Was the change approved?

Agent Foskett compared the timestamp and caller with the organisation's change records.

Was maintenance underway?
Was the rule intentionally disabled during tuning?
Was a deployment pipeline updating Sentinel content?
Did the owner of the caller identity expect the change?

A security control changing is evidence. Whether that change was legitimate requires context.

Did the same identity touch other Sentinel resources?

One changed rule might be a mistake. Multiple Sentinel changes by the same unexpected caller could indicate a larger problem. Agent Foskett widened the search around the identity and time window.
same-caller-sentinel-changes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let SuspiciousCaller = "analyst@contoso.com";
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue startswith "MICROSOFT.SECURITYINSIGHTS"
| where Caller =~ SuspiciousCaller
| project TimeGenerated,
          OperationNameValue,
          ActivityStatusValue,
          Caller,
          CallerIpAddress,
          ResourceId,
          CorrelationId
| order by TimeGenerated asc

The rule might not have been the only thing changed

Agent Foskett did not restrict the investigation to enablement state.

A detection can also be weakened by changing its KQL, schedule, threshold, entity mapping, suppression behaviour or other configuration.

A rule can remain enabled while becoming far less useful.

Detection tampering is not limited to an obvious Off switch.

Now investigate the blind window

Once the change timestamp was established, Agent Foskett defined the period between the rule becoming ineffective and being restored.

That interval became a hunting window.

Instead of asking which incidents Sentinel created, he ran the preserved detection logic directly against retained source telemetry.

If the detector was unavailable, hunt the data the detector should have evaluated.

Re-run the detection logic across the gap

The exact query depends on the analytics rule. Agent Foskett used the rule's preserved KQL across the period in which it was ineffective. This example shows the investigation pattern.
hunt-the-detection-gap.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let GapStart = datetime(2026-10-01 01:00:00);
let GapEnd   = datetime(2026-10-01 07:00:00);
DeviceProcessEvents
| where Timestamp between (GapStart .. GapEnd)
// Insert the preserved analytics-rule detection logic here
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine
| order by Timestamp asc

No incident did not mean no matching activity

If retained source telemetry contained events that would normally have satisfied the rule, the absence of an incident during the disabled period was expected.

The missing incident was a consequence of the detection gap — not proof that nothing happened.

Build the detection-tampering timeline

Rule stops producing alertsThe SOC notices an unexpected change in detection behaviour.
Source telemetry continuesThe underlying data confirms collection has not stopped.
Rule state confirmedThe analytics rule is found disabled or otherwise changed.
Audit event locatedSentinelAudit and AzureActivity establish the management-plane timeline.
Caller investigatedThe recorded identity, IP context and surrounding changes are examined.
Blind window huntedThe original detection logic is run across the period in which the rule was ineffective.

What the evidence can and cannot prove

SentinelAudit can record analytics-rule management operations when the required audit data is available and retained. AzureActivity can help reconstruct Microsoft Sentinel management actions and the recorded caller.

Neither fact alone proves malicious intent.

A disabled rule could result from approved maintenance, tuning, automation, human error or deliberate tampering.

Connect the configuration change, the identity behind it, the surrounding context and the activity that occurred during the detection gap.

The lesson

The SOC initially saw fewer alerts.

That sounded like good news.

It wasn't.

Agent Foskett confirmed the source telemetry was healthy, reconstructed the analytics-rule change, identified the caller and hunted the period in which the detection was unavailable.

Sometimes the attacker doesn't evade the detection. They remove the detection.
Investigation principle: When a normally active detection suddenly goes quiet, verify the data source and the detection configuration independently before concluding the threat has disappeared.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to investigate identity, endpoint, cloud and detection-engineering evidence.SOC Analyst AcademyBuild practical investigation, triage and detection skills across Microsoft security platforms.
The alerts stopped. The telemetry didn't.
Verify the rule. Find the change. Hunt the blind window.
Continue the Investigation

Final thought

Detection engineering is part of the security boundary.

Analytics rules determine which activity becomes visible to the SOC and which activity becomes an alert worth investigating.

So when a detection changes unexpectedly, the change itself deserves an investigation.

Find the rule.
Find the change.
Find the caller.
Then hunt everything that happened while the SOC was blind.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Who Disabled the Sentinel Analytics Rule?

This Agent Foskett investigation examines a disabled Microsoft Sentinel analytics rule using SentinelAudit, AzureActivity, control-plane evidence and KQL.

Investigating Microsoft Sentinel Analytics Rule Changes

Reconstruct analytics-rule management operations, identify the recorded caller, review related Sentinel changes and determine whether a change was approved or suspicious.

Hunting a Microsoft Sentinel Detection Gap

After establishing when a detection became ineffective, run the preserved analytics-rule logic across retained source telemetry to identify activity that may not have generated alerts or incidents during the gap.