MS SENTINEL

Audit Logs Account Enabled

// Account Enabled / Re-enabled (General) // Entra ID: AuditLogs "Enable account" // On-Prem AD: SecurityEvent 4722 (account enabled) // Optional context: 4725 (account disabled) to show prior disable events

// Account Enabled / Re-enabled by medhatfathy 
// Entra ID: AuditLogs "Enable account"
// On-Prem AD: SecurityEvent 4722 (account enabled)
// Optional context: 4725 (account disabled) to show prior disable events
union isfuzzy=true
(
    AuditLogs
    | where Category =~ "UserManagement"
    | where ActivityDisplayName =~ "Enable account"
    | where Result =~ "success"
    | mv-expand TargetResources
    | where tostring(TargetResources.type) =~ "User"
    | extend TargetUPN = tostring(TargetResources.userPrincipalName)
    | extend InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName),
             InitiatedByApp  = tostring(InitiatedBy.app.displayName)
),
(
    SecurityEvent
    | where EventID in (4722, 4725)  // 4722=Enabled, 4725=Disabled
    | extend X = parse_xml(EventData)
    | extend
        SubjectUserName   = tostring(X.EventData.Data[1]["#text"]),
        SubjectDomainName = tostring(X.EventData.Data[2]["#text"]),
        SubjectLogonId    = tostring(X.EventData.Data[3]["#text"]),
        TargetUserName    = tostring(X.EventData.Data[5]["#text"]),
        TargetDomainName  = tostring(X.EventData.Data[6]["#text"])
    | extend Action = case(EventID == 4722, "Account enabled (4722)",
                           EventID == 4725, "Account disabled (4725)",
                           "Account change")
)
| order by TimeGenerated desc

Rule Description

This rule detects user account enablement (re-enablement) events across:

Microsoft Entra ID (Azure AD) using AuditLogs
On-prem Active Directory using Windows SecurityEvent 4722

Re-enabling accounts can be legitimate (returning employee, remediation), but it can also indicate unauthorized persistence after compromise, privilege misuse, or bypass of joiner/mover/leaver controls.

Detection Logic

Entra ID side

Monitors AuditLogs for successful “Enable account” operations.
Extracts:
- TargetUPN from TargetResources.userPrincipalName
- Initiator identity (InitiatedBy.user.userPrincipalName) or app (InitiatedBy.app.displayName)
- CorrelationId for investigation pivoting

On-prem AD side

Monitors:
- 4722 (account enabled)
- Includes 4725 (account disabled) for context if available
Extracts:
- Subject (who performed it)
- Target (which account)
- Computer where the action was logged

Data Sources

Microsoft Entra ID AuditLogs
Windows SecurityEvent
- Event ID 4722 (enable)
- (Optional) 4725 (disable context)

Trigger Condition

Trigger when any of the following occurs:

Entra ID

Category = "UserManagement"
ActivityDisplayName = "Enable account"
Result = "success"
TargetResources.type = "User"

On-prem AD

SecurityEvent.EventID = 4722

Severity

Default: Medium

Elevate to High if:

Initiated by an unusual account (not helpdesk/IAM/admin automation)
Target account is privileged (admins, service accounts, executives)
Occurs outside business hours
Multiple accounts enabled by the same actor in a short period
Enablement is followed by suspicious sign-in behavior (new country/IP/device)

MITRE ATT&CK Mapping

T1098 - Account Manipulation
T1078 - Valid Accounts

Potential Risks

Reactivation of dormant/terminated accounts
Persistence after attacker disables/reenables accounts
Bypass of identity governance / lifecycle processes
Enabling privileged identities for escalation

Expected Behavior

Enablement performed by authorized administrators or approved identity workflows
Automated systems (e.g., HR/IAM) enabling accounts in controlled processes
Rare/exception-based enablements should be traceable via ticket/change record

Recommended Enhancements

Add privileged account watchlist and alert High immediately if target matches.
Correlate with SigninLogs within 0-60 minutes after enablement for rapid takeover detection.
Allowlist known initiator apps/accounts (e.g., identity automation, sync accounts).
Detect “disable then enable” sequence for the same user in a short window (common in attacker ops)

-- Palo Alto Firewall – Grayware DNS Communication Blocked

Description This alert indicates that the Palo Alto Networks firewall detected and blocked repeated outbound DNS communication attempts associated with grayware-related domains . The destination domains are associated with known grayware infrastructure, which is commonly linked to adware, potentially unwanted programs (PUPs), or low-risk malicious activity.

MITRE ATT&CK Mapping

T1071.004 – Application Layer Protocol: DNS
T1046 – Network Service Discovery (low confidence)
T1204 – User Execution (possible initial infection vector)

Goal: Identify internal hosts repeatedly attempting DNS communication with grayware or low-confidence malicious domains, even if the firewall blocks the traffic.

Use Case:

Detect early compromise
Identify adware / PUP infections
Find persistence attempts using DNS

CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| where Activity has "Grayware"
| where DestinationPort == "53"
| extend
SourceIP = SourceIP,
DestinationIP = DestinationIP,
ThreatName = ThreatName,
Action = DeviceAction
| summarize
EventCount = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
DestinationIPs = make_set(DestinationIP)
by
SourceIP,
ThreatName,
Action
| where EventCount >= 3
| order by EventCount desc

Scheduled Task Created/Modified/Deleted

// 4698 = Task Created, 4702 = Task Updated, 4699 = Task Deleted
SecurityEvent
| where EventID in (4698, 4702, 4699)
| extend X = parse_xml(EventData)
| extend
SubjectUserName = tostring(X.EventData.Data[1]["#text"]),
SubjectDomainName = tostring(X.EventData.Data[2]["#text"]),
SubjectLogonId = tostring(X.EventData.Data[3]["#text"]),
TaskName = tostring(X.EventData.Data[4]["#text"])
| extend TaskOperation = case(
EventID == 4698, "Created",
EventID == 4702, "Updated",
EventID == 4699, "Deleted",
"Other"
)
| project
TimeGenerated,
Computer,
EventID,
TaskOperation,
TaskName,
SubjectDomainName,
SubjectUserName,
SubjectLogonId,
Activity
| order by TimeGenerated desc

Rule Description

This rule detects Scheduled Task creation, modification, and deletion events on Windows endpoints by monitoring Windows Security logs. Scheduled tasks are a widely abused mechanism for persistence, privilege execution, and automated malware execution. While scheduled task operations may be legitimate (IT automation, software installation, updates), they are high-signal actions that often warrant review - especially when performed by unusual accounts or on sensitive systems.

Detection Logic

What it monitors

Windows SecurityEvent logs for:
- 4698 - A scheduled task was created
- 4702 - A scheduled task was updated
- 4699 - A scheduled task was deleted

What it extracts

The rule parses EventData to extract:

TaskName (the scheduled task path/name)
SubjectUserName / SubjectDomainName (who performed the change)
SubjectLogonId (session context)

Data Sources

Windows SecurityEvent
- Event IDs: 4698, 4702, 4699
- Requires Windows auditing for Task Scheduler events to be enabled and forwarded to Sentinel/Log Analytics.

Trigger Condition

Trigger when:

EventID in (4698, 4702, 4699)

(This is a broad “visibility” rule. Most teams tune it with allowlists and severity rules to reduce noise.)

Severity

Default: Medium

Elevate to High if any of these conditions apply:

SubjectUserName is not a known admin / IT automation / deployment account
Activity occurs on servers, domain controllers, or privileged endpoints
Task is created/updated under suspicious naming patterns (random strings, fake system names)
Activity occurs outside business hours
Same actor modifies tasks across multiple hosts in a short period

MITRE ATT&CK Mapping

T1053.005 - Scheduled Task/Job: Scheduled Task
T1098 - Account Manipulation (contextual, if tied to identity changes)
T1078 - Valid Accounts (when legitimate credentials are abused)

Potential Risks

Persistence via recurring or hidden task triggers
Execution of malicious payloads under elevated context (SYSTEM/admin)
Tampering with legitimate scheduled tasks
Deleting tasks to cover tracks after execution

Expected Behavior

Legitimate scheduled task operations commonly come from:

OS / application updates
Endpoint management platforms (SCCM/Intune/RMM)
Backup/monitoring agents
Approved administrative maintenance

Recommended Tuning

1) Reduce noise by focusing on Created/Updated only

| where EventID in (4698, 4702)

2) Add allowlist for known service/admin automation accounts

| where SubjectUserName !in~ ("SCCMService", "IntuneSvc", "RMMToolSvc")

3) Flag suspicious task locations (

Common suspicious areas:

\Microsoft\Windows\ (attackers blend in)
custom top-level tasks \<random>\
user-writable paths referenced in task actions (needs extra telemetry)

(If you also collect Sysmon / 4688, we can correlate the task to what it actually executes and upgrade this detection a lot.)

Password Reset – (Entra ID + On-Prem AD)

Detection Query (KQL)

// Password Reset Entra ID + On-Prem AD by medhat fathy
// Entra ID: "Reset user password" audit event (UserManagement)
// On-Prem AD: 4724 = An attempt was made to reset an account's password
union isfuzzy=true
(
    AuditLogs
    | where Category =~ "UserManagement"
    | where ActivityDisplayName =~ "Reset user password"
    | mv-expand TargetResources
    | extend TargetUPN = tostring(TargetResources.userPrincipalName)
    | extend InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName),
             InitiatedByApp  = tostring(InitiatedBy.app.displayName)
),
(
    SecurityEvent
    | where EventID == 4724
    | extend X = parse_xml(EventData)
    | extend
        SubjectUserName   = tostring(X.EventData.Data[1]["#text"]),
        SubjectDomainName = tostring(X.EventData.Data[2]["#text"]),
        SubjectLogonId    = tostring(X.EventData.Data[3]["#text"]),
        TargetUserName    = tostring(X.EventData.Data[5]["#text"]),
        TargetDomainName  = tostring(X.EventData.Data[6]["#text"])
)
| order by TimeGenerated desc

Notes

Entra password reset audit activity commonly appears as ActivityDisplayName = "Reset user password" under UserManagement.
On-prem admin password reset is SecurityEvent 4724 (“An attempt was made to reset an account’s password”).

Rule Description

This rule detects administrative password reset activity for user accounts in:

Microsoft Entra ID (Azure AD) via AuditLogs
On-prem Active Directory via Windows SecurityEvent 4724

Password resets can be legitimate (helpdesk support, account recovery), but they’re also a high-risk action used by attackers to take over accounts, maintain access, or disrupt incident response.

Detection Logic

What the rule monitors

Entra ID AuditLogs
- Category: UserManagement
- Activity: Reset user password
Windows SecurityEvent
- Event ID: 4724 (admin reset of another account’s password)

What it extracts

Target user (UPN in Entra / TargetUserName in AD)
Initiator (user or app in Entra; SubjectUserName/Domain in AD)
Correlation identifiers (Entra CorrelationId) for investigation pivoting

Data Sources

Microsoft Entra ID – AuditLogs
Windows SecurityEvent – Event ID 4724

Trigger Condition

Alert when either occurs:

AuditLogs.Category == "UserManagement" AND ActivityDisplayName == "Reset user password"
SecurityEvent.EventID == 4724

Severity

Default: Medium

Elevate to High if:

Reset performed by an unexpected admin/helpdesk account
Target account is privileged (Domain Admin, Global Admin, service accounts)
Reset happens outside business hours
Same initiator resets multiple accounts within a short period
Reset followed by anomalous sign-in activity (new IP/device/impossible travel)

MITRE ATT&CK Mapping

T1098 – Account Manipulation
T1078 – Valid Accounts

Potential Risks

Account takeover via forced password reset
Privilege escalation by resetting privileged identities
Persistence (resetting service account passwords to lock out defenders / maintain control)
Disruption (mass resets used as operational sabotage)

Expected Behavior

Helpdesk/admin resets for locked-out users
Approved identity recovery workflows
Automation accounts performing controlled resets (rare; should be tightly governed)

Recommended Tuning

Maintain an allowlist of approved reset operators (helpdesk group, IAM automation accounts).
Raise severity for resets on high-value targets (admins, service accounts, execs).
Add rate-based detection: same initiator resets ≥ N accounts in M minutes.
Correlate with sign-ins after reset (Entra SigninLogs) for immediate compromise signal.

Previousworking notes NextMDE Advanced Hunting (KQL)

Last updated 24 days ago

hashtagAudit Logs Account Enabled

hashtagRule Description

hashtagDetection Logic

hashtagSeverity

hashtagMITRE ATT&CK Mapping

hashtagPotential Risks

hashtagExpected Behavior

hashtagRecommended Enhancements

hashtagMITRE ATT&CK Mapping

hashtagScheduled Task Created/Modified/Deleted

hashtagRule Description

hashtagDetection Logic

hashtagWhat it monitors

hashtagWhat it extracts

hashtagData Sources

hashtagTrigger Condition

hashtagSeverity

hashtagMITRE ATT&CK Mapping

hashtagPotential Risks

hashtagExpected Behavior

hashtagRecommended Tuning

hashtag1) Reduce noise by focusing on Created/Updated only

hashtag2) Add allowlist for known service/admin automation accounts

hashtag3) Flag suspicious task locations (

hashtagPassword Reset – (Entra ID + On-Prem AD)

hashtagDetection Query (KQL)

hashtagRule Description

hashtagDetection Logic

hashtagWhat the rule monitors

hashtagWhat it extracts

hashtagData Sources

hashtagTrigger Condition

hashtagSeverity

hashtagMITRE ATT&CK Mapping

hashtagPotential Risks

hashtagExpected Behavior

hashtagRecommended Tuning

Audit Logs Account Enabled

Rule Description

Detection Logic

Severity

MITRE ATT&CK Mapping

Potential Risks

Expected Behavior

Recommended Enhancements

MITRE ATT&CK Mapping

Scheduled Task Created/Modified/Deleted

Rule Description

Detection Logic

What it monitors

What it extracts

Data Sources

Trigger Condition

Severity

MITRE ATT&CK Mapping

Potential Risks

Expected Behavior

Recommended Tuning

1) Reduce noise by focusing on Created/Updated only

2) Add allowlist for known service/admin automation accounts

3) Flag suspicious task locations (

Password Reset – (Entra ID + On-Prem AD)

Detection Query (KQL)

Rule Description

Detection Logic

What the rule monitors

What it extracts

Data Sources

Trigger Condition

Severity

MITRE ATT&CK Mapping

Potential Risks

Expected Behavior

Recommended Tuning