Elastic rules: 0w

[metadata]
creation_date = "2025/12/15"
maturity = "production"
updated_date = "2026/02/16"

[rule]
author = ["Elastic"]
description = """
This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and
involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are
more likely to be compromised.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Alerts From Multiple Integrations by User Name"
risk_score = 73
rule_id = "1dd99dbf-b98d-4956-876b-f13bc0ce017f"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*

// any alerts excluding low severity and the noisy ones
| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score > 21 and
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and 
        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0") and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
        // Top noisy influencing rules
        // Agent Spoofing - Mismatched Agent ID
        // Compression DLL Loaded by Unusual Process
        // Process Termination followed by Deletion 
        // Suspicious PrintSpooler Service Executable File Creation
        // Potential PrintNightmare File Modification
        // Multiple Vault Web Credentials Read
        // Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
        not kibana.alert.rule.rule_id in ("3115bd2c-0baa-4df0-80ea-45e474b5ef93", "d197478e-39f0-4347-a22f-ba654718b148", "09443c92-46b3-45a4-8f25-383b028b258d", "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", "5e87f165-45c2-4b80-bfa5-52822552c997", "44fc462c-1159-4fa8-b1b7-9b6296ab4f96", "994e40aa-8c85-43de-825e-15f665375ee8")
        
// group alerts by user.name and extract values of interest for alert triage
| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
        Esql.event_module_values = VALUES(event.module),
        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.message_values = VALUES(message),
        Esql.event_category_values = VALUES(event.category),
        Esql.event_action_values = VALUES(event.action),
        Esql.source_ip_values = VALUES(source.ip),
        Esql.destination_ip_values = VALUES(destination.ip),
        Esql.host_id_values = VALUES(host.id),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by user.name, user.id

// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels
| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
| keep user.name, Esql.*
'''
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Alerts From Multiple Integrations by User Name

The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.

### Possible investigation steps

- Review the alert details to identify the specific user involved and the different modules and rules that triggered the alert.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis

- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[metadata]
creation_date = "2026/07/06"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/06"

[rule]
author = ["Elastic"]
description = """
Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the
caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back
a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS
reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond
their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys
for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary.
"""
false_positives = [
    """
    Automation or SDK tooling configured with a Bedrock API key may call non-Bedrock APIs for benign
    credential validation. Ubiquitous no-op STS identity calls (GetCallerIdentity, GetSessionToken, 
    GetAccessKeyInfo) are excluded; other non-Bedrock activity by a BedrockAPIKey-* principal — recon, 
    privilege escalation, lateral movement, or exfiltration — is unexpected for an inference-only key. 
    Confirm the key and source in "source.ip"/"user_agent.original" are sanctioned.
    """,
]
from = "now-30m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock API Key Phantom User Activity Outside Bedrock"
note = """## Triage and analysis

### Investigating AWS Bedrock API Key Phantom User Activity Outside Bedrock

Amazon Bedrock API key phantom users ("BedrockAPIKey-*") exist only to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy. That policy grants Bedrock control-plane actions plus IAM, VPC, and KMS reconnaissance, so if an attacker adds standard IAM access keys (or a console login) to the phantom user, those credentials can be used for reconnaissance and lateral movement well beyond Bedrock.

This rule fires when a "BedrockAPIKey-*" user is the caller of an API request whose service is not Bedrock. Because the phantom user has no legitimate reason to act outside Bedrock, such activity is the privilege-escalation path realized.

### Possible investigation steps

- Review "aws.cloudtrail.user_identity.arn", "event.provider", and "event.action" to understand what non-Bedrock activity the phantom user performed.
- Inspect "source.ip"/"source.as.number" and "user_agent.original", and determine whether the phantom user holds IAM access keys or a login profile (the escalation pivot).
- Review the full sequence of the phantom user's actions for reconnaissance (IAM/EC2/STS enumeration) or attempts to access other resources.
- Correlate with the credential-addition event (CreateAccessKey/CreateLoginProfile on the same user).

### False positive analysis

- Phantom users are not meant to perform non-Bedrock activity, so this should be rare. Validate any intentional repurposing before excluding the identity.

### Response and remediation

- If unauthorized, disable and remove the phantom user's IAM access keys and login profile, and delete the phantom user after preserving forensic evidence.
- Review the account for resources the phantom user may have accessed or modified.
- Deploy an SCP denying "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to prevent the pivot.
"""
references = [
    "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response",
    "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html",
]
risk_score = 73
rule_id = "56788ae8-794b-4ade-affd-534aa5c9e28d"
setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type: "IAMUser"
    and user.name: BedrockAPIKey-*
    and not event.provider: (
        "bedrock.amazonaws.com" or "signin.amazonaws.com" or
        "agreement-marketplace.amazonaws.com" or "discovery-marketplace.amazonaws.com"
    )
    and not event.action: ("GetCallerIdentity" or "GetSessionToken" or "GetAccessKeyInfo")
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[metadata]
creation_date = "2024/10/25"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"


[rule]
author = ["Elastic"]
description = """
Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS).
While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation.
"""
false_positives = [
    "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes and to perform periodic tasks such as data backups, updates, or deployments.",
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS STS AssumeRole with New MFA Device"
note = """## Triage and analysis

### Investigating AWS STS AssumeRole with New MFA Device

AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation.

### Possible investigation steps

- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the `user.id` or `aws.cloudtrail.user_identity.arn` field to determine if the user is legitimate and authorized to use the new MFA device.
- Check the serialNumber in `aws.cloudtrail.request_parameters` to verify the registration and legitimacy of the new MFA device associated with the role assumption.
- Investigate the context of the AssumeRole action by examining surrounding events to understand if it was part of a legitimate workflow or an unusual activity.
- Cross-reference with any recent changes in user permissions or MFA device registrations.
- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe.
- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized.

### False positive analysis

- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules.
- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems.
- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns.
- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods.
- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods.

### Response and remediation

- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources.
- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used.
- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse.
- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts.
- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control.

## Setup

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html",
    "https://github.com/RhinoSecurityLabs/cloudgoat/blob/d5863b80afd082d853f2e8df1955c6393695a4da/scenarios/iam_privesc_by_key_rotation/README.md",
]
risk_score = 21
rule_id = "a22f566b-5b23-4412-880d-c6c957acd321"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS STS",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:aws.cloudtrail
    and event.provider:sts.amazonaws.com
    and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity)
    and event.outcome:success
    and aws.cloudtrail.flattened.request_parameters.serialNumber:*
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "aws.cloudtrail.resources.arn",    
    "aws.cloudtrail.resources.type",   
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[rule.new_terms]
field = "new_terms_fields"
value = ["user.id", "aws.cloudtrail.flattened.request_parameters.serialNumber"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[metadata]
creation_date = "2025/11/19"
integration = ["endpoint", "checkpoint_email"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate
the successful execution of a phishing attack.
"""
from = "now-1h"
interval = "45m"
language = "esql"
license = "Elastic License v2"
name = "Elastic Defend and Email Alerts Correlation"
risk_score = 73
rule_id = "c562a800-cf97-464e-9d6f-84db91e86e10"
severity = "high"
tags = [
    "Use Case: Threat Detection",
    "Rule Type: Higher-Order Rule",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Check Point Harmony Email & Collaboration",
    "Domain: Email",
    "Domain: Endpoint"
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-endpoint.alerts-*, logs-checkpoint_email.event-* metadata _id
// Email or Elastic Defend alerts where user name is populated
| where
  (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or
  (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts" and user.name is not null)

// extract target user name from email and endpoint alerts
| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null),
       elastic_defend_alert_user_name = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", user.name, null)
| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name)
| where Esql.target_user_name is not null

// group by Esql.target_user_name
| stats Esql.alerts_count = COUNT(*),
        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.event_module_values = VALUES(event.module),
        Esql.message_values = VALUES(message),
        Esql.event_action_values = VALUES(event.action),
        Esql.process_executable_values = VALUES(process.executable),
        Esql.host_id_values = VALUES(host.id),
        Esql.source_user_name = VALUES(source.user.name),
        Esql.rule_name_values = VALUES(rule.name)
        by Esql.target_user_name
// alert when same user is observed in an endpoint and email alert
| where Esql.event_module_distinct_count >= 2
| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values
'''
note = """## Triage and analysis
### Investigating Elastic Defend and Email Alerts Correlation

This rule correlates any Elastic Defend alert with an email security related alert by target user name.

### Possible investigation steps
- Review the alert details to identify the specific host and users involved.
- Investigate the individual alerts for the target user name and see if they are related.
- Review all emails received from Esql.source_user_name and if there are other impacted users.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis
- Legitimate email marked as suspicious.
- Legitimate file or behavior marked as suspicious by Elastic Defend.
- Unrelated alerts where the target user name is too generic.

### Response and remediation
- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[metadata]
creation_date = "2025/04/29"
integration = ["azure"]
maturity = "production"
promotion = true
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in
activity such as anonymized IP addresses, unlikely travel, password spray, and more.
"""
false_positives = [
    """
    Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is
    expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP
    ranges.
    """,
    """
    Users who frequently travel or access their accounts from different geographic locations may trigger this rule due
    to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding
    exceptions for specific users.
    """,
    """
    Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism.
    If this is expected behavior, consider adjusting the rule or adding exceptions for specific users.
    """,
]
from = "now-9m"
index = ["logs-azure.identity_protection-*"]
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Entra ID Protection - Risk Detection - Sign-in Risk"
note = """## Triage and analysis

This rule detects sign-in risk detection events via Microsoft Entra ID Protection. It identifies various risk event types such as anonymized IP addresses, unlikely travel, password spray, and more. These events can indicate potential malicious activity or compromised accounts.

### Possible investigation steps

- Review the `azure.identityprotection.properties.risk_event_type` field to understand the specific risk event type detected.
- Check the `azure.identityprotection.properties.risk_level` field to determine the severity of the risk event.
- Check the `azure.identityprotection.properties.risk_detail` field for additional context on the risk event.
- Review the `azure.correlation_id` field to correlate this event with other related events in your environment.
- Review the `azure.identityprotection.properties.additional_info` field for any additional information provided by Entra ID Protection.
- Review the `azure.identityprotection.properties.detection_timing_type` field to understand when the risk event was detected. Offline detections may indicate a delayed response to a potential threat while real-time detections indicate immediate risk assessment.
- Check the `azure.identityprotection.properties.user_principal_name` field to identify the user account associated with the risk event. This can help determine if the account is compromised or if the risk event is expected behavior for that user. Triage the user account with other events from Entra ID audit or sign-in logs to identify any suspicious activity or patterns.

### False positive analysis

- Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP ranges.
- Users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users.
- Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users.

### Response and remediation
- Investigate the user account associated with the risk event to determine if it has been compromised or if the risk event is expected behavior.
- If the risk event indicates a compromised account, take appropriate actions such as resetting the password, enabling multi-factor authentication, or disabling the account temporarily.
- Review authentication material such as primary refresh tokens (PRTs) or OAuth tokens to ensure they have not been compromised. If necessary, revoke these tokens to prevent further access.
- Implement sign-in risk policies in Entra ID Protection to automatically respond to risk events, such as requiring multi-factor authentication or blocking sign-ins from risky locations.
- Ensure multi-factor authentication is enabled for all user accounts to provide an additional layer of security against compromised accounts.
- Consider using high risk detections and conditional access evaluations to enforce stricter security measures for accounts or enable access revocation.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://github.com/dirkjanm/ROADtools",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
    "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection",
    "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/",
]
risk_score = 73
rule_id = "064a2e08-25da-11f0-b1f1-f661ea17fbcd"
setup = """#### Required Microsoft Entra ID Protection Logs
To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration.

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Entra ID",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Use Case: Risk Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "azure.identity_protection" and
    event.action: "User Risk Detection" and
    azure.identityprotection.properties.activity: "signin" and
    not azure.identityprotection.properties.risk_state: (
        "remediated" or "dismissed" or "confirmedSafe"
    )
'''


[[rule.severity_mapping]]
field = "azure.identityprotection.properties.risk_level"
operator = "equals"
severity = "high"
value = "high"

[[rule.severity_mapping]]
field = "azure.identityprotection.properties.risk_level"
operator = "equals"
severity = "medium"
value = "medium"

[[rule.severity_mapping]]
field = "azure.identityprotection.properties.risk_level"
operator = "equals"
severity = "low"
value = "low"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"




[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"


[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.identityprotection.properties.risk_event_type",
    "azure.identityprotection.properties.risk_level",
    "azure.identityprotection.properties.risk_detail",
    "azure.identityprotection.properties.user_principal_name",
    "azure.identityprotection.properties.user_display_name",
    "azure.identityprotection.properties.risk_state",
    "azure.identityprotection.properties.risk_type",
    "azure.identityprotection.properties.risk_reasons",
    "azure.identityprotection.properties.ip_address",
    "azure.identityprotection.properties.location",
    "azure.identityprotection.properties.detection_timing_type",
]

[metadata]
creation_date = "2026/03/03"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/07/02"

[rule]
author = ["Elastic"]
description = """
Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. 
Intended to surface RMM clients, scripts, or other non-browser activity contacting these services.
"""
from = "now-7205m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "First Time Seen DNS Query to RMM Domain"
note = """## Triage and analysis

### Investigating First Time Seen DNS Query to RMM Domain

This rule flags DNS queries to commonly abused RMM or remote access domains when the requesting process is not a browser. Legitimate RMM and remote desktop software is frequently abused for C2, persistence, and lateral movement.

### Possible investigation steps

- Identify the process process.executable that performed the DNS query and verify if it is an approved RMM or remote access tool.
- Review the full process tree and parent process to understand how the binary was launched.
- Check process.code_signature for trusted RMM publishers; unsigned or unexpected signers may indicate abuse or trojanized installers.
- Correlate with the companion rule "First Time Seen Remote Monitoring and Management Tool" for the same host to see if the RMM process was first-time seen.
- Investigate other alerts for the same host or user in the past 48 hours.

### False positive analysis

- Approved RMM or remote support tools used by IT will trigger this rule; consider allowlisting by process path or code signer for known managed tools.
- Some updaters or installers (e.g. signed by the RMM vendor) may resolve these domains; combine with process name or parent context to reduce noise.

### Response and remediation

- If unauthorized RMM use is confirmed: isolate the host, remove the RMM software, rotate credentials, and block the domains at DNS/firewall where policy permits.
- Enforce policy that only approved RMM tools from approved publishers may be used, and only by authorized staff.
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Sysmon Event ID 22 - DNS Query](https://ela.st/sysmon-event-22-setup)
"""

references = [
    "https://attack.mitre.org/techniques/T1219/002/",
    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a",
    "https://lolrmm.io/",
]
risk_score = 47
rule_id = "e5f6a7b8-c9d0-8e1f-2a3b-4c5d6e7f8a9b"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon"
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-endpoint.events.network-*, logs-windows.sysmon_operational-* METADATA _index
| WHERE host.os.type == "windows"
    AND event.category == "network"
    AND event.action in ("lookup_requested", "DNSEvent (DNS query)")
    AND dns.question.name IS NOT NULL

// Exclude browser processes
| WHERE NOT
    process.name IN (
        "chrome.exe", "msedge.exe", "MicrosoftEdge.exe", "MicrosoftEdgeCP.exe",
        "firefox.exe", "iexplore.exe", "safari.exe", "brave.exe",
        "opera.exe", "vivaldi.exe", "msedgewebview2.exe"
    )

// Extract the parent domain (last two labels, e.g. example.com)
| GROK dns.question.name """(?:[^.]+\.)+(?<parent_domain>[^.]+\.[^.]+)$"""
| EVAL parent_domain = COALESCE(parent_domain, dns.question.name)

// Known RMM parent domains, add or remove entries here as your environment changes.
| WHERE parent_domain IN (
    "01com.com",
    "247ithelp.com",
    "action1.com",
    "addigy.com",
    "aeroadmin.com",
    "ammyy.com",
    "anydesk.com",
    "anyplace-control.com",
    "anysupport.net",
    "atera.com",
    "aurelius.host",
    "auvik.com",
    "aweray.com",
    "aweray.net",
    "backdrop.cloud",
    "barracudamsp.com",
    "beamyourscreen.com",
    "beanywhere.com",
    "beinsync.com",
    "beinsync.net",
    "beyondtrustcloud.com",
    "bomgar.com",
    "bomgarcloud.com",
    "centrastage.net",
    "centuriontech.com",
    "connectwise.com",
    "crossloop.com",
    "dameware.com",
    "datto.com",
    "datto.net",
    "deskday.ai",
    "deskroll.com",
    "desktopstreaming.com",
    "distantdesktop.com",
    "donkz.nl",
    "dwservice.net",
    "ehorus.com",
    "electric.ai",
    "emcosoftware.com",
    "ericom.com",
    "fastsupport.com",
    "fastviewer.com",
    "fixme.it",
    "fleetdeck.io",
    "gatherplace.com",
    "gatherplace.net",
    "getgo.com",
    "getscreen.me",
    "gotoassist.at",
    "gotoassist.com",
    "gotoassist.me",
    "gotohttp.com",
    "gotoresolve.com",
    "goverlan.com",
    "heartbeatrm.com",
    "helpme.net",
    "helpwire.app",
    "hoptodesk.com",
    "hostedrmm.com",
    "immy.bot",
    "immybot.com",
    "imperosoftware.com",
    "instanthousecall.com",
    "instanthousecall.net",
    "intelliadmin.com",
    "internapcdn.net",
    "internetid.ru",
    "iperius-rs.com",
    "iperius.net",
    "iperiusremote.com",
    "islonline.com",
    "islonline.net",
    "itarian.com",
    "itsupport247.net",
    "jumpcloud.com",
    "jumpdesktop.com",
    "jumpto.me",
    "kabuto.io",
    "kabutoservices.com",
    "kaseya.com",
    "kaseya.net",
    "kickidler.com",
    "laplink.com",
    "level.io",
    "liongard.com",
    "litemanager.com",
    "litemanager.ru",
    "logicnow.com",
    "logmein-gateway.com",
    "logmein.com",
    "logmeininc.com",
    "logmeinrescue.com",
    "logmeinrescue.eu",
    "lunixar.com",
    "meshcentral.com",
    "mikogo.com",
    "mikogo4.com",
    "miradore.com",
    "msp360.com",
    "mygreenpc.com",
    "n-able.com",
    "naverisk.com",
    "nchuser.com",
    "netop.com",
    "netsupportmanager.com",
    "netsupportsoftware.com",
    "netviewer.com",
    "ninjaone.com",
    "ninjarmm.com",
    "ninjarmm.net",
    "nomachine.com",
    "ntrsupport.com",
    "opti-tune.com",
    "optitune.us",
    "oray.com",
    "oray.net",
    "panorama9.com",
    "parsec.app",
    "parsecusercontent.com",
    "pcvisit.de",
    "pilixo.com",
    "playanext.com",
    "pulseway.com",
    "qetqo.com",
    "r-hud.net",
    "real-time-collaboration.com",
    "remmon.hu",
    "remote.it",
    "remote.management",
    "remotecall.com",
    "remotedesktop.com",
    "remotepc.com",
    "remotetopc.com",
    "remoteutilities.com",
    "remotix.com",
    "remotly.com",
    "repairshopr.com",
    "rmansys.ru",
    "rmmservice.ca",
    "rmmservice.eu",
    "royalapps.com",
    "rport.io",
    "rudesktop.ru",
    "rustdesk.com",
    "rview.com",
    "screenconnect.com",
    "screenmeet.com",
    "scrn.mt",
    "servably.com",
    "server-eye.de",
    "set.me",
    "setme.net",
    "showmypc.com",
    "signalserver.xyz",
    "simple-help.com",
    "skyfex.com",
    "sorillus.com",
    "splashtop.com",
    "splashtop.eu",
    "spyanywhere.com",
    "spytech-web.com",
    "startsupport.com",
    "superops.ai",
    "superops.com",
    "superopsalpha.com",
    "superopsbeta.com",
    "supremocontrol.com",
    "swi-rc.com",
    "swi-tc.com",
    "syncroapi.com",
    "syncromsp.com",
    "syspectr.com",
    "system-monitor.com",
    "systemmonitor.us",
    "tacticalrmm.com",
    "tailscale.com",
    "teamviewer.com",
    "techinline.net",
    "tele-desk.com",
    "tiflux.com",
    "tightvnc.com",
    "tmate.io",
    "todesk.com",
    "twingate.com",
    "ultraviewer.net",
    "ultravnc.com",
    "vnc.com",
    "weezo.me",
    "weezo.net",
    "xeox.com",
    "zoho.eu",
    "zohoassist.com",
    "zohoassist.jp"
)

// Aggregate by parent domain and get 1st time seen timestamp as well as unique count of agents
| STATS
    event_count = COUNT(*),
    Esql.first_time_seen = MIN(@timestamp),
    Esql.count_distinct_host_id = COUNT_DISTINCT(host.id),
    Esql.process_executable_values = VALUES(process.executable),
    Esql.dns_question_name_values = VALUES(dns.question.name),
    Esql.host_name_values = VALUES(host.name),
    Esql.host_id_values = VALUES(host.id),
    Esql.user_name_values = VALUES(user.name),
    Esql.user_id_values = VALUES(user.id),
    Esql.namespace_values = VALUES(data_stream.namespace) BY parent_domain

// Calculate the time difference between first time seen and rule execution time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())

// First time seen is within 6m of the rule execution time and first seen in the last 5 days as per the rule from schedule and limited to 1 unique host
| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1

// populate fields for rule exception and triage
| eval host.name = MV_FIRST(Esql.host_name_values),
       host.id = MV_FIRST(Esql.host_id_values),
       user.name = MV_FIRST(Esql.user_name_values),
       user.id = MV_FIRST(Esql.user_id_values),
       data_stream.namespace = MV_FIRST(Esql.namespace_values),
       process.executable = MV_FIRST(Esql.process_executable_values),
       dns.question.name = MV_FIRST(Esql.dns_question_name_values)
| keep host.name, host.id, user.name, user.id, data_stream.namespace, process.executable, dns.question.name, Esql.*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1219"
name = "Remote Access Tools"
reference = "https://attack.mitre.org/techniques/T1219/"
[[rule.threat.technique.subtechnique]]
id = "T1219.002"
name = "Remote Desktop Software"
reference = "https://attack.mitre.org/techniques/T1219/002/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[metadata]
creation_date = "2026/01/21"
integration = ["cloud_defend", "kubernetes"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of forbidden
interactive Kubernetes API requests. An adversary may need to execute interactive Kubernetes API requests to gain access
to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the
Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the
cluster. Attackers may attempt to access resources that are forbidden by the authorization policy. Note that this rule may
not trigger if the authorization token of the request is expanded within the process argument list, as the length of the
"process.args" field may lead to the field being ignored.
"""
false_positives = [
    """
    There is a potential for false positives if the direct interactive Kubernetes API requests are used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
    """
    There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
    to the wrong container.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*", "logs-kubernetes.audit_logs-*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Forbidden Direct Interactive Kubernetes API Request"
note = """ ## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Forbidden Direct Interactive Kubernetes API Request

This rule correlates an interactive command execution inside a container with a Kubernetes API request that is explicitly forbidden, signaling hands-on-keyboard probing and unauthorized access attempts. It matters because attackers use live shells to enumerate cluster resources and test privileges for lateral movement or escalation. Example: after compromising a pod, an operator opens a shell and runs kubectl get secrets or curls the API server with the pod’s token, repeatedly receiving 403 Forbidden.

### Possible investigation steps

- Correlate the pod, container, namespace, node, and service account from the alert, then quickly pull the matching audit entries to see the verb, resource, requestURI, and userAgent for the forbidden calls.
- Determine whether the container image normally includes utilities like kubectl/curl/openssl or if they were dropped into the pod, and review recent file writes and package installs to differentiate admin debugging from hands-on-keyboard activity.
- Inspect the pod’s service account bindings and effective RBAC in the target namespace to confirm least privilege and understand why the request was denied, then check for other successful API requests from the same identity around the same timeframe.
- Review network connections from the pod to the API server (and any proxies) during the session to validate direct access paths, source IPs, and whether a mounted service account token from /var/run/secrets was used.
- Validate whether this was an authorized SRE/debug session by contacting the workload owner and checking for recent kubectl exec or ephemeral debug activity; if not expected, expand the search for similar forbidden attempts from other pods.

### False positive analysis

- An authorized kubectl exec or ephemeral debug session inside a pod where an engineer runs kubectl or curl to probe API resources and, because the pod’s service account is intentionally least‑privileged, the requests are forbidden as expected.
- Benign interactive troubleshooting that mistakenly uses the wrong namespace or queries cluster‑scoped endpoints from within the container (e.g., curl/openssl to the API server), causing the audit logs to show forbid decisions even though no malicious access was attempted.

### Response and remediation

- Immediately terminate the interactive shell (e.g., sh/bash) in the offending container and isolate the pod by applying a deny-egress NetworkPolicy in its namespace that blocks outbound connections to https://kubernetes.default.svc and the API server IPs.
- Revoke and rotate credentials by deleting the pod and its ServiceAccount token Secret, temporarily setting automountServiceAccountToken: false on the workload, and redeploying with a new ServiceAccount after validating RBAC least privilege.
- Remove attacker tooling and persistence by rebuilding the container image to exclude kubectl/curl/openssl/socat/ncat, clearing writable volume mounts that contain dropped binaries or scripts, and redeploying from a trusted registry.
- Sweep for spread by identifying pods running the same image or on the same node and terminating any interactive processes issuing Kubernetes API requests from within containers, then restart those workloads cleanly.
- Escalate to incident response if you observe successful API operations (200/201) on secrets, configmaps, or RBAC objects, exec into other pods, or privileged container settings (privileged=true, hostNetwork, or hostPID), indicating lateral movement or credential compromise.
- Harden going forward by tightening RBAC on the new ServiceAccount, enforcing Gatekeeper/OPA policies to deny images that include kubectl/curl and block interactive shells, setting readOnlyRootFilesystem and dropping NET_ADMIN, and restricting API server access via egress controls.
"""
risk_score = 47
rule_id = "5d1c962d-5d2a-48d4-bdcf-e980e3914947"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Data Source: Kubernetes",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
     process.name in ("wget", "curl", "openssl", "socat", "ncat", "kubectl") or
     (
       /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
       process.args in (
         "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget",
         "ssl_client", "/bin/ssl_client", "/usr/bin/ssl_client", "/usr/local/bin/ssl_client",
         "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl",
         "openssl", "/bin/openssl", "/usr/bin/openssl", "/usr/local/bin/openssl",
         "socat", "/bin/socat", "/usr/bin/socat", "/usr/local/bin/socat",
         "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
         "kubectl", "/bin/kubectl", "/usr/bin/kubectl", "/usr/local/bin/kubectl"
       ) and
       /* default exclusion list to not FP on default multi-process commands */
       not process.args in (
         "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
         "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
         "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
         "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
       )
     )
   ) and process.interactive == true and container.id like "*"
  ] by orchestrator.resource.name
  [any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted") and
  `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid"
  ] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name` 
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[rule.threat.technique]]
id = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[metadata]
creation_date = "2020/09/23"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A
subscription is a named resource representing the stream of messages to be delivered to the subscribing application.
"""
false_positives = [
    """
    Subscription deletions may be done by a system or network administrator. Verify whether the user email, resource
    name, and/or hostname should be making changes in your environment. Subscription deletions by unfamiliar users or
    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Pub/Sub Subscription Deletion"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating GCP Pub/Sub Subscription Deletion

Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities.

### Possible investigation steps

- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion.
- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity.
- Investigate the context of the deleted subscription by examining the associated project and any related resources to understand the potential impact on the application or service.
- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions.
- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk.
- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary.

### False positive analysis

- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts.
- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags.
- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations.

### Response and remediation

- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized.
- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions.
- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed.
- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise.
- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected.
- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/pubsub/docs/overview"]
risk_score = 21
rule_id = "cc89312d-6f47-48e4-a87c-4977bd4633c3"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Log Auditing",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.DeleteSubscription and event.outcome:success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[metadata]
creation_date = "2024/11/04"
integration = ["endpoint", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP
forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to
pivot between networks, exfiltrate data, or establish command and control channels.
"""
from = "now-9m"
index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "logs-crowdstrike.fdr*"]
language = "eql"
license = "Elastic License v2"
name = "IPv4/IPv6 Forwarding Activity"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating IPv4/IPv6 Forwarding Activity

IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse.

### Possible investigation steps

- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert.
- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process.
- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials.
- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement.
- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns.
- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk.

### False positive analysis

- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts.
- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows.
- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns.
- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts.

### Response and remediation

- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration.
- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity.
- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
- Implement network segmentation to limit the ability of attackers to pivot between networks in the future.
- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse."""
risk_score = 21
rule_id = "5a138e2e-aec3-4240-9843-56825d0bc569"
severity = "low"
tags = [
  "Domain: Endpoint",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Command and Control",
  "Data Source: Elastic Defend",
  "Data Source: SentinelOne",
  "Data Source: Elastic Endgame",
  "Resources: Investigation Guide",
  "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event", "ProcessRollup2") and
?process.parent.executable != null and process.command_line like (
  "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*",
  "*/proc/sys/net/ipv6/conf/all/forwarding*"
) and (
  (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or
  (
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
    process.command_line like "*echo *"
  )
) and
not (
  process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") or
  ?process.parent.executable == "/usr/sbin/sshd" or
  ?process.parent.args in (
    "/usr/lib/pritunl/usr/bin/pritunl", "/usr/bin/dockerd-rootless.sh", "/etc/rc.d/init.d/network", "/etc/rc0.d/K90network"
  )  or
  ?process.parent.args like "/etc/untangle/post-network-hook.d/*"
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1090"
name = "Proxy"
reference = "https://attack.mitre.org/techniques/T1090/"

[[rule.threat.technique.subtechnique]]
id = "T1090.001"
name = "Internal Proxy"
reference = "https://attack.mitre.org/techniques/T1090/001/"

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[metadata]
creation_date = "2021/03/29"
integration = ["o365"]
maturity = "production"
updated_date = "2026/05/27"

[rule]
author = ["Elastic", "Gary Blackwell", "Austin Songer", "Marco Pedrinazzi"]
description = """
Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based
on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can
abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or
having the corresponding privileges.
"""
false_positives = [
    """
    Users and Administrators can create inbox rules for legitimate purposes. Verify if it complies with the company
    policy and done with the user's consent. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "eql"
license = "Elastic License v2"
name = "M365 Exchange Inbox Forwarding Rule Created"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating M365 Exchange Inbox Forwarding Rule Created

Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities.

### Possible investigation steps

- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters.
- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address.
- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange.
- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities.
- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise.
- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized.

### False positive analysis

- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations.
- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule.
- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period.
- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule.
- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior.

### Response and remediation

- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules.
- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings.
- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access.
- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure.
- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised.
- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes.
- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide",
    "https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps",
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide",
    "https://raw.githubusercontent.com/PwC-IR/Business-Email-Compromise-Guide/main/Extractor%20Cheat%20Sheet.pdf",
    "https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/"
]
risk_score = 47
rule_id = "ec8efb0c-604d-42fa-ac46-ed1cfbc38f78"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Domain: Email",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Configuration Audit",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
web where
    event.provider == "Exchange" and
    event.action in (
        "New-InboxRule",
        "Set-InboxRule",
        "Set-Mailbox",
        "Set-TransportRule",
        "New-TransportRule"
    ) and event.outcome == "success" and
    (
        (?o365.audit.Parameters.ForwardTo != null and not endsWith~(?o365.audit.Parameters.ForwardTo, user.domain)) or
        (?o365.audit.Parameters.ForwardAsAttachmentTo != null and not endsWith~(?o365.audit.Parameters.ForwardAsAttachmentTo, user.domain)) or
        (?o365.audit.Parameters.ForwardingAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingAddress, user.domain)) or
        (?o365.audit.Parameters.ForwardingSmtpAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingSmtpAddress, user.domain)) or
        (?o365.audit.Parameters.RedirectTo != null and not endsWith~(?o365.audit.Parameters.RedirectTo, user.domain)) or
        (?o365.audit.Parameters.RedirectToRecipients != null and not endsWith~(?o365.audit.Parameters.RedirectToRecipients, user.domain)) or
        (?o365.audit.Parameters.RedirectMessageTo != null and not endsWith~(?o365.audit.Parameters.RedirectMessageTo, user.domain)) or
        (?o365.audit.Parameters.BlindCopyTo != null and not endsWith~(?o365.audit.Parameters.BlindCopyTo, user.domain))
    )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1114"
name = "Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/"
[[rule.threat.technique.subtechnique]]
id = "T1114.003"
name = "Email Forwarding Rule"
reference = "https://attack.mitre.org/techniques/T1114/003/"



[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/20"
integration = ["o365"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies administrative actions in the Microsoft 365 Security & Compliance Center including cmdlet execution, RBAC
changes, security insights, and user permission modifications. These events can indicate legitimate administrative
activity or potential defense evasion through security control modifications such as DLP policy removal, compliance
rule changes, or privilege escalation. This building block rule generates security events for correlation, threat
hunting, and telemetry collection.
"""
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Security Compliance Admin Signal"
references = [
    "https://learn.microsoft.com/en-us/purview/audit-log-activities",
    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#enum-auditlogrecordtype---type-edmint32",
]
risk_score = 21
rule_id = "314557e1-a642-4dbc-af43-321bc04b6618"
setup = """### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Purview",
    "Use Case: Threat Detection",
    "Use Case: Configuration Auditing",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:o365.audit and
    event.code:(SecurityComplianceCenterEOPCmdlet or SecurityComplianceInsights or SecurityComplianceRBAC or SecurityComplianceUserChange)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"