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

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmedhat.gitbook.io/whoami/working-notes/ms-sentinel.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.