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 2 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