> For the complete documentation index, see [llms.txt](https://0xmedhat.gitbook.io/whoami/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xmedhat.gitbook.io/whoami/working-notes/ms-sentinel.md).

# 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

```kql
// 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 

1. **Add privileged account watchlist** and alert High immediately if target matches.
2. **Correlate with SigninLogs** within 0-60 minutes after enablement for rapid takeover detection.
3. **Allowlist known initiator apps/accounts** (e.g., identity automation, sync accounts).
4. **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

```kql
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

```kql
// 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

```kusto
| where EventID in (4698, 4702)
```

#### 2) Add allowlist for known service/admin automation accounts

```kusto
| 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)

```kusto
// 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&#x20;

* 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.

***