Elastic rules: 2e

[metadata]
creation_date = "2020/10/19"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
This rule detects the Active Directory query tool, AdFind.exe. AdFind has legitimate purposes, but it is frequently
leveraged by threat actors to perform post-exploitation Active Directory reconnaissance. The AdFind tool has been
observed in Trickbot, Ryuk, Maze, and FIN6 campaigns. For Winlogbeat, this rule requires Sysmon.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "AdFind Command Activity"
note = """## Triage and analysis

### Investigating AdFind Command Activity

[AdFind](http://www.joeware.net/freetools/tools/adfind/) is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many [examples](https://thedfirreport.com/category/adfind/) of this tool being adopted by ransomware and criminal groups and used in compromises.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Examine the command line to determine what information was retrieved by the tool.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.

### False positive analysis

- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators.
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in isolation, so reviewing previous logs/activity from impacted machines can be very telling.

### Related rules

- Windows Network Enumeration - 7b8bfc26-81d2-435e-965c-d722ee397ef1
- Enumeration of Administrator Accounts - 871ea072-1b71-4def-b016-6278b505138d
- Enumeration Command Spawned via WMIPrvSE - 770e0c4d-b998-41e5-a62e-c7901fd7f470

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

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:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

references = [
    "http://www.joeware.net/freetools/tools/adfind/",
    "https://thedfirreport.com/2020/05/08/adfind-recon/",
    "https://www.fireeye.com/blog/threat-research/2020/05/tactics-techniques-procedures-associated-with-maze-ransomware-incidents.html",
    "https://www.cybereason.com/blog/dropping-anchor-from-a-trickbot-infection-to-the-discovery-of-the-anchor-malware",
    "https://www.fireeye.com/blog/threat-research/2019/04/pick-six-intercepting-a-fin6-intrusion.html",
    "https://usa.visa.com/dam/VCOM/global/support-legal/documents/fin6-cybercrime-group-expands-threat-To-ecommerce-merchants.pdf",
]
risk_score = 21
rule_id = "eda499b8-a073-4e35-9733-22ec71f57f3a"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "AdFind*.exe" or ?process.pe.original_file_name == "AdFind.exe") and
  process.args : ("objectcategory=computer", "(objectcategory=computer)",
                  "objectcategory=person", "(objectcategory=person)",
                  "objectcategory=subnet", "(objectcategory=subnet)",
                  "objectcategory=group", "(objectcategory=group)",
                  "objectcategory=organizationalunit", "(objectcategory=organizationalunit)",
                  "objectcategory=attributeschema", "(objectcategory=attributeschema)",
                  "domainlist", "dcmodes", "adinfo", "dclist", "computers_pwnotreqd", "trustdmp")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"

[[rule.threat.technique]]
id = "T1018"
name = "Remote System Discovery"
reference = "https://attack.mitre.org/techniques/T1018/"

[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[rule.threat.technique.subtechnique]]
id = "T1069.002"
name = "Domain Groups"
reference = "https://attack.mitre.org/techniques/T1069/002/"


[[rule.threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"
[[rule.threat.technique.subtechnique]]
id = "T1087.002"
name = "Domain Account"
reference = "https://attack.mitre.org/techniques/T1087/002/"


[[rule.threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"


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

[metadata]
creation_date = "2024/05/02"
integration = ["aws_bedrock"]
maturity = "production"
updated_date = "2025/09/25"

[rule]
author = ["Elastic"]
description = """
Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated
attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring
exhorbitant costs.
"""
false_positives = ["Legitimate misunderstanding by users or overly strict policies"]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User"
note = """## Triage and analysis

### Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User

Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.

Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.

#### Possible investigation steps

- Identify the user account that attempted to use denied models.
- Investigate other alerts associated with the user account during the past 48 hours.
- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?
- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.

### False positive analysis

- Verify the user account that attempted to use denied models, is a legitimate misunderstanding by users or overly strict policies.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.
    - Identify any regulatory or legal ramifications related to this activity.
- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html",
    "https://atlas.mitre.org/techniques/AML.T0015",
    "https://atlas.mitre.org/techniques/AML.T0034",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 73
rule_id = "17261da3-a6d0-463c-aac8-ea1718afcd20"
setup = """## Setup

This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:

https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html
"""
severity = "high"
tags = [
    "Domain: LLM",
    "Data Source: AWS Bedrock",
    "Data Source: AWS S3",
    "Resources: Investigation Guide",
    "Use Case: Policy Violation",
    "Mitre Atlas: T0015",
    "Mitre Atlas: T0034",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws_bedrock.invocation-*

// Filter for access denied errors from GenAI responses
| where gen_ai.response.error_code == "AccessDeniedException"

// keep ECS and response fields
| keep
  user.id,
  gen_ai.request.model.id,
  cloud.account.id,
  gen_ai.response.error_code

// count total denials per user/model/account
| stats
    Esql.ml_response_access_denied_count = count(*)
  by
    user.id,
    gen_ai.request.model.id,
    cloud.account.id

// Filter for users with repeated denials
| where Esql.ml_response_access_denied_count > 3

// sort by volume of denials
| sort Esql.ml_response_access_denied_count desc
'''



[rule.investigation_fields]
field_names = ["user.id", "cloud.account.id", "gen_ai.request.model.id", "total_denials"]

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

[rule]
author = ["Elastic"]
description = """
Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a
foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement
(accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently
be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to
establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is
distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API
calls that grant model entitlements and agreements.
"""
false_positives = [
    """
    Cloud administrators and machine-learning teams routinely enable model access, submit use cases, and accept model
    end-user license agreements (EULAs) during account onboarding or when adopting a new foundation model. Verify that
    the principal, source IP, and user agent are expected and that the change aligns with a known onboarding or
    provisioning activity before escalating. If this activity is expected and authorized for specific principals,
    consider adding exceptions for those users or roles.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Foundation Model Access Enabled or Entitlement Granted"
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 AWS Bedrock Foundation Model Access Enabled or Entitlement Granted

Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls.

Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable.

This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy.

### Possible investigation steps

- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access.
- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved.
- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious.
- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region.
- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise.
- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking).
- Contact the resource owner to confirm whether enabling this model access was planned and authorized.

### False positive analysis

- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows.
- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected.

### Response and remediation

- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model.
- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action.
- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs.
- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure.
- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html"
]
risk_score = 47
rule_id = "aed4b9d5-f853-40cf-8489-4fdcff03e272"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "bedrock.amazonaws.com"
    and event.action: (
        "PutFoundationModelEntitlement" or
        "PutUseCaseForModelAccess" or
        "CreateFoundationModelAgreement"
    )
    and event.outcome: "success"
'''


[[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.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other
malware may do this to prevent system recovery.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Backup Deletion with Wbadmin"
note = """## Triage and analysis

### Investigating Backup Deletion with Wbadmin

Windows Server Backup stores the details about your backups (what volumes are backed up and where the backups are located) in a file called a backup catalog, which ransomware victims can use to recover corrupted backup files. Deleting these files is a common step in threat actor playbooks.

This rule identifies the deletion of the backup catalog using the `wbadmin.exe` utility.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Check if any files on the host machine have been encrypted.

### False positive analysis

- Administrators can use this command to delete corrupted catalogs, but overall the activity is unlikely to be legitimate.

### Related rules

- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9
- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
- If any backups were affected:
  - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

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:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

risk_score = 21
rule_id = "581add16-df76-42bb-af8e-c979bfb39a59"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "wbadmin.exe" or ?process.pe.original_file_name == "WBADMIN.EXE") and
  process.args : ("catalog", "backup", "systemstatebackup") and process.args : "delete"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1485"
name = "Data Destruction"
reference = "https://attack.mitre.org/techniques/T1485/"

[[rule.threat.technique]]
id = "T1490"
name = "Inhibit System Recovery"
reference = "https://attack.mitre.org/techniques/T1490/"


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

[metadata]
creation_date = "2020/09/02"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies .lnk shortcut file downloaded from outside the local network. These shortcut files are commonly used in
phishing campaigns.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Downloaded Shortcut Files"
risk_score = 47
rule_id = "39157d52-4035-44a8-9d1a-6f8c5f580a07"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1
'''

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

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 Downloaded Shortcut Files

Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in these files, often distributing them via phishing. The detection rule identifies suspicious .lnk files created on Windows systems, especially those downloaded from external sources, indicating potential phishing attempts. This is achieved by monitoring file creation events and zone identifiers, which help trace the file's origin.

### Possible investigation steps

- Review the file creation event details to identify the specific .lnk file and its associated metadata, such as the file path and creation timestamp.
- Examine the zone identifier value to confirm that the file was indeed downloaded from an external source, as indicated by a value greater than 1.
- Investigate the source of the download by checking network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded.
- Analyze the contents of the .lnk file to detect any embedded commands or scripts that may indicate malicious intent.
- Check for any related alerts or events on the same host around the time of the .lnk file creation to identify potential follow-up actions or additional threats.
- Assess the user account associated with the file creation event to determine if the account has been compromised or if the user was targeted in a phishing campaign.

### False positive analysis

- Corporate software deployments may trigger the rule when legitimate .lnk files are distributed across the network. Users can create exceptions for known software distribution servers to prevent these false positives.
- Automated backup or synchronization tools that create .lnk files as part of their normal operation can be mistaken for threats. Identifying and excluding these tools from the rule can reduce unnecessary alerts.
- User-created shortcuts for frequently accessed network resources might be flagged. Monitoring and excluding specific user activities or directories where these shortcuts are commonly created can help manage these false positives.
- Some legitimate applications may download .lnk files as part of their update process. Identifying these applications and adding them to an exception list can prevent false alerts.

### Response and remediation

- Isolate the affected system from the network to prevent further spread of the potential threat.
- Quarantine the suspicious .lnk file to prevent execution and further analysis.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
- Review and remove any unauthorized or suspicious user accounts or privileges that may have been created or altered as a result of the phishing attempt.
- Restore the system from a known good backup if any critical system files or configurations have been compromised.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Update security policies and rules to block similar phishing attempts in the future, such as restricting the execution of .lnk files from untrusted sources."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[rule.threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"

[[rule.threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"



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

[rule]
description = """
Identifies when a script interpreter executes a base64-encoded Empire stager. Empire is penetration testing software
that is often utilized by attackers.
"""
id = "b7974ff6-82ff-4743-9e07-1c6901b1f0ea"
license = "Elastic License v2"
name = "Empire Stager Execution"
os_list = ["linux", "macos"]
reference = ["https://github.com/EmpireProject/Empire", "https://github.com/BC-SECURITY/Empire"]
version = "1.0.31"

query = '''
process where event.type == "start" and event.action == "exec" and
process.name like ("python*", "osascript", "sh", "bash", "dash", "ksh", "tcsh", "zsh") and
process.command_line like~ "*exec(base64.b64decode*aW1wb3J0IHN5cztpbXBvcnQg*"
'''

min_endpoint_version = "7.15.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[threat.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1132"
name = "Data Encoding"
reference = "https://attack.mitre.org/techniques/T1132/"
[[threat.technique.subtechnique]]
id = "T1132.001"
name = "Standard Encoding"
reference = "https://attack.mitre.org/techniques/T1132/001/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/05/15"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker
(MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers
abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications.
The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune
Enrollment, extend or tune exclusions for your tenant after baselining broker traffic.
"""
false_positives = [
    """
    Legitimate broker sign-ins to first-party Microsoft resources that use alternate well-known IDs, regional variants,
    or new Microsoft services not yet in the exclusion list may match. Third-party applications that integrate with MAB
    for delegated authentication can also appear. Baseline `resource_id` and `resource_display_name` for your
    environment and add exclusions for approved resources.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource"
note = """## Triage and analysis

### Investigating Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource

Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.resource_id`,
`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and
`user_agent.original`.

Determine whether the resource is a known line-of-business application, partner integration, or Microsoft service not
represented in the rule exclusion list.

### Possible investigation steps

- Resolve `resource_id` in Entra ID enterprise applications and compare with change records or app governance inventory.
- Correlate with `azure.signinlogs` and `azure.graphactivitylogs` for follow-on API calls from the same session.
- Review conditional access results and risk detections for the same user and time window.

### Response and remediation

- If unauthorized, revoke refresh tokens for the user, review consent and app permissions, and reset credentials per policy.
- Escalate per incident procedures when the resource corresponds to sensitive APIs or high-privilege applications.
"""
references = [
    "https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in",
    "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs",
    "https://any.run/malware-trends/tycoon/",
]
risk_score = 73
rule_id = "4f95e0f8-18b7-459a-b8b5-b2f5c94bf6eb"
severity = "high"
setup = """
Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must include `azure.signinlogs.properties.app_id` and
`azure.signinlogs.properties.resource_id`. Tune the exclusion list for first-party resource identifiers your tenant
expects from the Microsoft Authentication Broker.
"""
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and
event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
azure.signinlogs.properties.resource_id:(* and not 
    ("00000002-0000-0000-c000-000000000000" or
    "90a2e5d2-fd7a-4a2e-bc90-3dc50ae8e3ee" or
    "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" or
    "d4ebce55-015a-49b5-a083-c84d1797ae8c" or
    "00000003-0000-0000-c000-000000000000" or 
    "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2")
)
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.geo.country_name",
    "event.outcome",
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.session_id",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.resource_id",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.authentication_protocol",
    "azure.tenant_id",
]

[[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 = "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 = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

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

[rule]
author = ["Elastic"]
description = """
Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk
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 - User Risk"
note = """## Triage and analysis

This rule detects user 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://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 = "4b1ee53e-3fdc-11f0-8c24-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" or "Risky user") and
    azure.identityprotection.properties.activity: "user" 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 = "2023/04/11"
integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies instances where the 'find' command is started on a Linux system with arguments targeting specific VM-related
paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization
software, and their presence in the find command arguments may indicate that a threat actor is attempting to search for,
analyze, or manipulate VM-related files and configurations on the system.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "ESXI Discovery via Find"
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 ESXI Discovery via Find

VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.

### Possible investigation steps

- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process.
- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns.
- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system.
- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings.

### False positive analysis

- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks.
- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule.
- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts.
- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities.
- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files.
- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity.
- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities.
- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = [
    "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
]
risk_score = 47
rule_id = "33a6752b-da5e-45f8-b13a-5f094c09522f"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and
process.name == "find" and process.args like ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and
not ?process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
'''

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

[[rule.threat.technique]]
id = "T1083"
name = "File and Directory Discovery"
reference = "https://attack.mitre.org/techniques/T1083/"

[[rule.threat.technique]]
id = "T1518"
name = "Software Discovery"
reference = "https://attack.mitre.org/techniques/T1518/"

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

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2025/12/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Detects a new IP address used for a GitHub user not previously seen in the last 14 days.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of IP Address For GitHub User"
risk_score = 21
rule_id = "3af4cb9b-973f-4c54-be2b-7623c0e21b2b"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Initial Access",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset:"github.audit" and event.category:"configuration" and
github.actor_ip:* and user.name:*
'''


[[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.new_terms]
field = "new_terms_fields"
value = ["user.name", "github.actor_ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2021/11/08"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or
use them to add users as local admins.
"""
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Group Policy Abuse for Privilege Addition"
references = [
    "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md",
    "https://labs.withsecure.com/tools/sharpgpoabuse",
]
risk_score = 73
rule_id = "b9554892-5e0e-424b-83a0-5aef95aa43bf"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Active Directory",
    "Resources: Investigation Guide",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where host.os.type == "windows" and event.code: "5136" and
  winlog.event_data.AttributeLDAPDisplayName: "gPCMachineExtensionNames" and
  winlog.event_data.AttributeValue: "*827D319E-6EAC-11D2-A4EA-00C04F79F83A*" and
  winlog.event_data.AttributeValue: "*803E14A0-B4FB-11D0-A0D0-00A0C90F574B*"
'''

note = """## Triage and analysis

### Investigating Group Policy Abuse for Privilege Addition
#### Possible investigation steps

- What GPO extension change was preserved?
  - Focus: `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, `winlog.event_data.OperationType`, `winlog.event_data.ObjectDN`, and `winlog.event_data.ObjectGUID` confirm the 5136 "gPCMachineExtensionNames" GPO change.
  - Implication: escalate when the value enables Security CSE GUID "827D319E-6EAC-11D2-A4EA-00C04F79F83A" plus Computer Restricted Groups GUID "803E14A0-B4FB-11D0-A0D0-00A0C90F574B" on an unexpected GPO; lower concern only when artifacts/scope confirm a recognized hardening refresh.
- Who changed the GPO, and from where?
  - Focus: identify the writer: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`.
  - Hint: on `winlog.computer_name`, find "4624" where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; search "4648" on `winlog.event_data.SubjectLogonId` for explicit credentials, then check `source.ip`, `winlog.logon.type`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetServerName`. Missing logon telemetry is unresolved, not benign.
    - $investigate_0
    - $investigate_1
  - Implication: escalate when the writer is outside GPO admin cohort, uses an unusual source or direct domain-controller session, or shows alternate-credential use; lower concern when account/session match a recognized GPO administration path.
- Do surrounding directory changes show a coordinated GPO update?
  - Why: "5136" can record related object modifications; `winlog.event_data.OpCorrelationID` separates one GPO edit from directory noise.
  - Focus: reconstruct surrounding "5136" records from the same domain controller with `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, changed attribute, and operation type.
  - Hint: prefer one `winlog.event_data.OpCorrelationID`; if absent, use the same `winlog.event_data.SubjectLogonId` plus tight `@timestamp` and `winlog.record_id` ordering. $investigate_2
  - Implication: escalate when the operation touches other sensitive GPO attributes or combines this privilege path with GPO execution or persistence; lower concern when the 5136 set stays narrow and artifact/scope checks confirm one recognized security-template task.
- What grants and recipients does the SYSVOL template define?
  - Why: the alert proves machine security extensions were enabled; rights or local group membership live in "GptTmpl.inf" under the SYSVOL policy folder.
  - Focus: use the policy GUID from the CN portion of `winlog.event_data.ObjectDN` with `winlog.event_data.DSName` to inspect "Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf"; map SIDs/groups to admin tier, service-account role, and whether `winlog.event_data.SubjectUserSid` benefits. Treat `winlog.event_data.ObjectGUID` as the AD object pivot, not the SYSVOL folder name, unless it matches the CN.
  - Hint: if SYSVOL is unavailable, preserve `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and expected policy path; suspicious writer/session or companion 5136 evidence makes the missing grant an evidence gap.
  - Implication: escalate when "[Privilege Rights]" grants high-impact rights ("SeDebugPrivilege", "SeTakeOwnershipPrivilege", "SeEnableDelegationPrivilege", or "SeImpersonatePrivilege"), when "[Group Membership]" adds broad/unexpected identities to local Administrators ("S-1-5-32-544"), or when the writer benefits; lower concern when entries and recipients match the recognized baseline for that GPO.
- Which computers consume the changed GPO?
  - Why: GPO privilege abuse scales with link scope, security filtering, WMI filters, and reach to admin workstations, servers, or domain controllers.
  - Focus: use `winlog.event_data.ObjectDN` and the recovered policy-folder GUID to review GPO links, security filtering, WMI filters, and roles.
  - Hint: if scope data is unavailable, preserve `winlog.event_data.ObjectDN` and `winlog.event_data.ObjectGUID`; do not assume narrow scope, and escalate if writer/session, companion-change, or grant evidence is suspicious.
  - Implication: prioritize escalation when the GPO reaches domain controllers, admin workstations, servers, or broad workstations; lower urgency only when scope matches the recognized maintenance/test population established by the grant evidence.
- If evidence remains suspicious or unresolved, do related events show broader abuse?
  - Focus: after confirming `user.id` is the writer, review recent modifying-account activity. $investigate_3
  - Hint: compare with activity scoped to the same `winlog.event_data.ObjectGUID`. $investigate_4
  - Implication: escalate scope when the writer or same GPO appears in other GPO abuse, credential access, privilege escalation, or lateral movement; quiet history only narrows scope and cannot close unresolved grant or blast-radius questions.
- Escalate for unexpected writer/session, companion change, high-impact grant, sensitive scope, or related abuse; close only when the same GPO, writer/session, recovered grants, and scope prove one recognized hardening or restricted-groups workflow; if evidence stays mixed or incomplete, preserve GPO artifacts and escalate.

### False positive analysis

- Authorized GPO hardening, restricted-groups maintenance, red-team, or detection-validation can update "gPCMachineExtensionNames" and "GptTmpl.inf". Confirm only when writer/session, GPO object, `winlog.event_data.OpCorrelationID`, recovered template entries, and linked scope match the admin tier, change window, template, or test plan. Quiet history supports but cannot replace that proof; if any anchor diverges, do not close as benign.
- For exceptions, validate one authorized workflow matching writer SID, GPO object, grant pattern, and linked OU/host scope. Build the exception from that pattern, not broad `event.code`, "gPCMachineExtensionNames", or GPO modification activity.

### Related rules

- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e
- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046

### Response and remediation

- If confirmed benign, reverse temporary containment and document writer SID, GPO object, logon/correlation IDs, recovered "GptTmpl.inf", and OU/host scope matching the workflow. Keep exceptions narrow and tied to that stable pattern.
- If suspicious but unconfirmed, preserve the "5136" event, object and writer/session IDs, `winlog.event_data.OpCorrelationID`, `winlog.computer_name`, exported "GptTmpl.inf", available SYSVOL metadata, linked "4624"/"4648" events, and related activity before containment. Use reversible controls first: restrict affected-GPO edits, limit the writer's GPO admin path, or monitor linked systems during scoping. Disable accounts or roll back GPOs only if follow-on abuse or malicious grants are confirmed.
- If confirmed malicious, preserve evidence first, remove unauthorized "[Privilege Rights]" or "[Group Membership]" entries, roll the GPO back to known-good state, and verify exported SYSVOL metadata before forcing policy refresh. Use identity/endpoint response to contain the writer account and admin workstation identified by `source.ip` or `winlog.logon.type`; if unavailable, escalate with writer/session, GPO, correlation, and SYSVOL artifacts.
- Review linked OUs and affected computers before deleting artifacts or forcing "gpupdate"; complete scoping before evidence changes.
- Harden: restrict GPO edit rights to dedicated admin tiers, retain "5136" auditing, keep security-template baselines, and document abuse variants or visibility gaps for detection engineering.
"""

setup = """## Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-changes
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.id",
    "winlog.event_data.SubjectUserName",
    "winlog.event_data.SubjectUserSid",
    "winlog.event_data.SubjectLogonId",
    "winlog.event_data.ObjectDN",
    "winlog.event_data.ObjectGUID",
    "winlog.event_data.AttributeLDAPDisplayName",
    "winlog.event_data.AttributeValue",
    "winlog.event_data.OperationType",
    "winlog.event_data.OpCorrelationID",
    "winlog.event_data.DSName",
    "host.id",
    "winlog.computer_name",
]

[transform]

[[transform.investigate]]
label = "Linked logon for the GPO writer"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-24h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Explicit-credential events for the GPO writer"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-24h/h"
relativeTo = "now"

[[transform.investigate]]
label = "5136 events in this GPO change operation"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
    { excluded = false, field = "winlog.event_data.OpCorrelationID", queryType = "phrase", value = "{{winlog.event_data.OpCorrelationID}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Recent events associated with the source account"
description = ""
providers = [
  [
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Events associated with the modified GPO"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[[rule.threat.technique.subtechnique]]
id = "T1484.001"
name = "Group Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/001/"

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

[rule]
description = "Identifies attempt to download remote content by commonly abused ingress tool transfer binaries."
id = "4e3a6c40-37b7-466f-8ed4-8e40b2cf3c5b"
license = "Elastic License v2"
name = "Ingress Transfer via Windows Utility"
os_list = ["windows"]
version = "1.0.3"

query = '''
process where event.action == "start" and
(
 ((process.name : "CertUtil.exe" or process.pe.original_file_name == "CertUtil.exe") and
  process.args : "-urlcache" and process.command_line : "*http*") or

 ((process.pe.original_file_name == "CertReq.exe" or process.name : "CertReq.exe") and
  process.args : "-Post" and process.command_line : "*http*")
 )
'''

min_endpoint_version = "7.15.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/05/07"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/05/07"

[rule]
author = ["Elastic"]
description = """
Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control
cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service
DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server,
database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently
connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database
credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every
pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS
configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.
"""
false_positives = [
    """
    Cluster administrators may legitimately update CoreDNS configuration for forwarding, stub domains, or cluster DNS
    troubleshooting. Baseline approved operators and automation identities; tune exclusions for known change pipelines.
    """,
]
from = "now-9m"
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes CoreDNS or Kube-DNS Configuration Modified"
note = """## Triage and analysis

### Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified

Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified.
If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard
rewrites, or unexpected forward/proxy targets.

### Possible investigation steps

- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.

### Response and remediation

- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.
"""
references = [
    "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
    "https://coredns.io/plugins/rewrite/",
    "https://attack.mitre.org/techniques/T1565/001/",
]
risk_score = 73
rule_id = "a643e6b8-ba2a-45f1-8d71-d265bfe2ae43"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"kubernetes.audit_logs" and 
kubernetes.audit.objectRef.resource:"configmaps" and
kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
kubernetes.audit.objectRef.namespace:"kube-system" and
kubernetes.audit.verb:("update" or "patch" or "delete") and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and 
not user.name:(
  system\:serviceaccount\:kube-system\:coredns or
  system\:serviceaccount\:kube-system\:kube-dns or
  system\:node\:* or
  eks\:* or aksService or acsService
)
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"

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

[metadata]
creation_date = "2024/06/17"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame.
Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list
of known usernames and passwords to gain unauthorized access to user accounts.
"""
false_positives = [
    "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
    "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Okta User Authentication Events with Same Device Token Hash"
note = """## Triage and analysis

### Investigating Multiple Okta User Authentication Events with Same Device Token Hash

This rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.

#### Possible investigation steps:
- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.
- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.
    - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.
- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.
    - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.
- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
    - Historical analysis should indicate if this device token hash is commonly associated with the user.
- Review the `okta.event_type` field to determine the type of authentication event that occurred.
    - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.
    - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.
- Examine the `okta.outcome.result` field to determine if the authentication was successful.
- Review the past activities of the actor(s) involved in this action by checking their previous actions.
- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
    - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.

### False positive analysis:
- A user may have legitimately started a session via a proxy for security or privacy reasons.
- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
    - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.
    - Shared systems such as Kiosks and conference room computers may be used by multiple users.
    - Shared working spaces may have a single endpoint that is used by multiple users.

### Response and remediation:
- Review the profile of the users involved in this action to determine if proxy usage may be expected.
- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.
- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).
    - If MFA is already enabled, consider resetting MFA for the users.
- If any of the users are not legitimate, consider deactivating the user's account.
- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
    - If so, confirm with the user this was a legitimate request.
    - If so and this was not a legitimate request, consider deactivating the user's account temporarily.
        - Reset passwords and reset MFA for the user.
- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.
    - This will prevent future occurrences of this event for this device from triggering the rule.
"""
references = [
    "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
    "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 21
rule_id = "95b99adc-2cda-11ef-84e1-f661ea17fbce"
setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
severity = "low"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-okta*
| where
    data_stream.dataset == "okta.system" and
    (event.action like "user.authentication.*" or event.action == "user.session.start") and
    okta.debug_context.debug_data.dt_hash != "-" and
    okta.outcome.reason == "INVALID_CREDENTIALS"
| keep
    event.action,
    okta.debug_context.debug_data.dt_hash,
    okta.actor.id,
    okta.actor.alternate_id,
    okta.outcome.reason
| stats
    Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)
  by
    okta.debug_context.debug_data.dt_hash,
    okta.actor.alternate_id
| where
    Esql.okta_actor_id_count_distinct > 20
| sort
    Esql.okta_actor_id_count_distinct desc
'''


[[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.subtechnique]]
id = "T1110.004"
name = "Credential Stuffing"
reference = "https://attack.mitre.org/techniques/T1110/004/"

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

[metadata]
creation_date = "2021/09/27"
integration = ["windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies suspicious access to an LSASS handle via DuplicateHandle from an unknown call trace module. This may indicate
an attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via DuplicateHandle in LSASS"
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 Potential Credential Access via DuplicateHandle in LSASS

The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities.

### Possible investigation steps

- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40".
- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request.
- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities.
- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS.
- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps.
- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes.

### False positive analysis

- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts.
- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives.
- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening.
- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities.
- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation.
- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts.
- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function."""
references = ["https://github.com/CCob/MirrorDump"]
risk_score = 47
rule_id = "02a4576a-7480-4284-9327-548a806b5e48"
setup = """## Setup

This rule requires Sysmon telemetry to be enabled and ingested.

Setup instructions: https://ela.st/sysmon-event-10-setup
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.code == "10" and

 /* LSASS requesting DuplicateHandle access right to another process */
 process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and

 /* call is coming from an unknown executable region */
 winlog.event_data.CallTrace : "*UNKNOWN*"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[rule.threat.technique.subtechnique]]
id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"



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

[rule]
description = """
Identifies creation or modification of a .vscode/tasks.json file followed by opening the current project in a short
time. Threat actors distribute malicious repositories that embed autorun task configurations to phish for credentials or
execute payloads when a developer opens the project in Visual Studio Code.
"""
id = "ad058e28-8504-4bfe-9b91-22d24d903ede"
license = "Elastic License v2"
name = "Potential Execution via VS Code Tasks"
os_list = ["linux", "windows"]
reference = [
    "https://www.jamf.com/blog/threat-actors-expand-abuse-of-visual-studio-code/",
    "https://about.gitlab.com/blog/how-to-detect-and-prevent-contagious-interview-ide-attacks/",
    "https://kl4r10n.tech/blog/dprk-new-malware",
]
version = "1.0.2"

query = '''
sequence with maxspan=30s
  [file where event.action in ("creation", "modification") and file.name == "tasks.json" and
   process.name in (
     // Windows browsers
     "chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "opera.exe", "vivaldi.exe",
     // macOS browsers (bundle exec names)
     "Google Chrome", "Google Chrome Helper", "Chromium", "Chromium Helper",
     "firefox", "Firefox", "Safari", "SafariTP",
     "Brave Browser", "Opera", "Vivaldi", "Arc",
     // Linux browsers
     "google-chrome", "google-chrome-stable", "chromium", "chromium-browser",
     "firefox", "firefox-esr", "brave-browser", "opera", "vivaldi-bin",
     // Windows archivers
     "7z.exe", "7zFM.exe", "7zG.exe", "winrar.exe", "tar",  "unzip.exe", "winscp.exe",
     // macOS/Linux archivers and fetch tools
     "unzip", "tar", "bsdtar", "curl", "wget",
     // Version control / package managers
     "git", "git.exe", "gh", "gh.exe", "npm", "npm.exe", "node", "node.exe",
     "pip", "pip3", "python", "python3", "python.exe",
     // Shells / script runners
     "powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe",
     "bash", "zsh", "sh", "fish", "dash"
   ) and
   file.path : ("?:\\*\\.vscode\\tasks.json", "/*/.vscode/tasks.json")]
  [process where event.type == "start" and event.action in ("start", "exec") and
   process.name in ("code", "cursor", "Code.exe", "Cursor.exe", "codium", "VSCodium.exe", "windsurf", "Windsurf.exe") and
   process.args == "."]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 1

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[threat.technique.subtechnique]]
id = "T1195.001"
name = "Compromise Software Dependencies and Development Tools"
reference = "https://attack.mitre.org/techniques/T1195/001/"


[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2021/01/11"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a suspicious zip file prepended with special characters. Sandboxed Microsoft Office
applications on macOS are allowed to write files that start with special characters, which can be combined with an
AutoStart location to achieve sandbox evasion.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Microsoft Office Sandbox Evasion"
references = [
    "https://i.blackhat.com/USA-20/Wednesday/us-20-Wardle-Office-Drama-On-macOS.pdf",
    "https://www.mdsec.co.uk/2018/08/escaping-the-sandbox-microsoft-office-on-macos/",
    "https://desi-jarvis.medium.com/office365-macos-sandbox-escape-fcce4fa4123c",
]
risk_score = 73
rule_id = "d22a85c6-d2ad-4cc4-bf7b-54787473669a"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a macOS System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "macos" and event.action in ("modification", "rename") and file.name like~ "~$*.zip"
'''
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 Potential Microsoft Office Sandbox Evasion

Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, bypassing sandbox restrictions. The detection rule identifies such files, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts and mitigate risks.

### Possible investigation steps

- Review the file creation event details to confirm the presence of a zip file with a name starting with special characters, as indicated by the file.name field.
- Examine the file path and location to determine if it aligns with known AutoStart locations, which could indicate an attempt to achieve persistence.
- Investigate the user account associated with the event to assess if the activity is expected or if the account may have been compromised.
- Check for any related events or activities on the same host around the time of the alert, such as other file creations or modifications, to identify potential patterns or additional suspicious behavior.
- Analyze the host's recent network activity to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
- Correlate the event with other alerts or logs from the same host or user to build a comprehensive timeline of activities and assess the broader impact or intent.

### False positive analysis

- Files with special character prefixes created by legitimate applications or processes, such as temporary files generated by Microsoft Office during normal operations, may trigger the rule. Users can create exceptions for known benign applications that frequently generate such files.
- Automated backup or synchronization tools that compress files into zip archives with special character prefixes might be flagged. Identify these tools and exclude their file creation events from the rule.
- Development or testing environments where zip files with special character prefixes are used for legitimate purposes can cause false positives. Implement exclusions for these environments to prevent unnecessary alerts.
- User-generated zip files with special character prefixes for personal organization or naming conventions may be mistakenly identified. Educate users on naming conventions and adjust the rule to exclude specific user directories if needed.

### Response and remediation

- Isolate the affected macOS system from the network to prevent further potential spread or data exfiltration.
- Quarantine the suspicious zip file to prevent execution and further analysis.
- Conduct a thorough scan of the system using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes.
- Review and secure AutoStart locations on the affected system to prevent unauthorized applications from executing at startup.
- Restore any affected files from a known good backup to ensure system integrity and continuity.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems may be affected.
- Update security policies and endpoint protection configurations to block the creation and execution of files with suspicious naming patterns, enhancing future detection and prevention capabilities."""


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

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

[[rule.threat.technique.subtechnique]]
id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"

[[rule.threat.technique]]
id = "T1497"
name = "Virtualization/Sandbox Evasion"
reference = "https://attack.mitre.org/techniques/T1497/"

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