Elastic rules: 2k

[metadata]
creation_date = "2020/07/02"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies a password recovery request for the AWS account root user.
In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. 
This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy.
"""
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Sign-In Root Password Recovery Requested"
note = """## Triage and analysis

### Investigating AWS Sign-In Root Password Recovery Requested

In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access.

### Possible investigation steps

- **Verify the event details.**  
  Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated.

- **Confirm legitimacy.**  
  Contact the account owner or credential custodian to verify whether they initiated the password recovery.  
  AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this.

- **Check CloudTrail for related events.**  
  Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request.

- **Assess IP reputation and location.**  
  Validate whether the `source.ip` aligns with known admin networks or expected geographies.  
  Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents.

- **Correlate with other alerts.**  
  Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe.

### False positive analysis

- **Expected maintenance activity.**  
  If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed.  
- **Testing or account verification.**  
  Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation.

### Response and remediation

**Immediate actions**
- **If confirmed legitimate:**  
  - Ensure that MFA is enabled and operational for the root account.  
  - Encourage rotation of the root password if not recently updated.  
- **If unconfirmed or suspicious:**  
  - Immediately reset the root password using the legitimate AWS recovery email link.  
  - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA).  
  - Check for new successful root logins or unexpected IAM changes since the recovery attempt.  

**Evidence preservation**
- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes).  
- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours.  
- Store this evidence in a restricted S3 bucket with Object Lock enabled.

**Scoping and investigation**
- Review all root-level activities within the past 24–48 hours.  
  Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`.  
- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications.

**Recovery and hardening**
- Confirm MFA is enforced on the root account.  
- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active).  
- Secure the associated email account (password reset notifications are sent there).  
- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions.  
- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process.

### Additional information

- **AWS Incident Response Playbooks:**    
  and [`IRP-Credential-Compromise.md`](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md) for procedures related to root account credential recovery and unauthorized access attempts.  
- **AWS Customer Playbook Framework:**  
  See [`Compromised_IAM_Credentials.md`](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md) for guidance on containment, evidence collection, and recovery validation.  
- **AWS Documentation:** [AWS account root user best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html).  
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
"""

references = ["https://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
risk_score = 73
rule_id = "69c420e8-6c9e-4d28-86c0-8a2be2d1e78c"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Sign-In",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:aws.cloudtrail and 
event.provider:signin.amazonaws.com and 
event.action:PasswordRecoveryRequested and 
event.outcome:success
'''

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

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

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

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

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

[metadata]
creation_date = "2025/01/16"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/22"

[rule]
author = ["Elastic"]
description = """
This rule detects the process of copying or moving files from or to the "/boot" directory on Linux systems. The "/boot"
directory contains files that are essential for the system to boot, such as the kernel and initramfs images. Attackers
may copy or move files to the "/boot" directory to modify the boot process, which can be leveraged to maintain access to
the system.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Boot File Copy"
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 Boot File Copy
The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications.

### Possible investigation steps

- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'.
- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'.
- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior.
- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events.
- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images.
- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern.

### False positive analysis

- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule.
- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria.
- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged.
- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory.
- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary.
- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications.
- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes."""
risk_score = 21
rule_id = "5bda8597-69a6-4b9e-87a2-69a7c963ea83"
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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "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", "start") and
process.name in ("cp", "mv") and process.parent.executable != null and process.args like~ "/boot/*" and not (
  process.parent.name in ("update-initramfs", "dracut", "grub-mkconfig", "shim-install", "sudo", "activate-theme", "update-grub-gfxpayload", "grub-pc.postinst") or
  process.parent.executable like~ ("/usr/lib/kernel/install.d/*", "/tmp/newroot/*", "/var/lib/dpkg/info/*") or
  process.parent.args like~ ("/usr/bin/mkinitcpio", "/var/tmp/rpm-tmp.*", "/var/lib/dpkg/info/*") or
  process.parent.executable in (
    "/var/lib/aws-replication-agent/migration_scripts/suse_to_aws.bash", "/usr/sbin/flash-kernel", "/usr/sbin/weak-modules",
    "/etc/cron.hourly/check_mau", "/usr/bin/update-microcode-initrd", "/bin/run-parts", "/usr/sbin/mkinitramfs", "/usr/sbin/grub2-mkconfig",
    "/usr/bin/supermin5", "/sbin/weak-modules", "/usr/sbin/nv-update-initrd", "/usr/libexec/platform-python", "/bin/kernel-install",
    "/usr/bin/oracle-database-preinstall-19c-verify", "/usr/libexec/grubby/prune_debug"
  ) or
  process.command_line == "/bin/cp /usr/local/ASR/Vx/scripts/vCon//Configuration.info /boot/" or
  ?process.working_directory in ("/var/lib/aws-replication-agent", "/opt/sentinelone/bin", "/tmp/MobilityAgentAutoUpgrade/package") or
  (
    process.name == "cp" and
    process.parent.args in (
      "/etc/kernel/postrm.d/zz-proxmox-boot", "/etc/kernel/postinst.d/zz-proxmox-boot", "/usr/lib/kernel/install.d/20-grub.install",
      "/usr/bin/dracut", "/bin/dracut", "/usr/sbin/shim-install", "/sbin/dracut", "/opt/McAfee/ens/esp/scripts/modversion-check.sh",
      "//opt/McAfee/ens/esp/scripts//modversion-check.sh", "/usr/sbin/update-grub-legacy-ec2", "/usr/bin/foreman-generate-bootloaders",
      "/usr/share/grub2/themes/SLE/activate-theme", "/usr/sbin/dracut", "/usr/sbin/flash-kernel", "/usr/lib/kernel/install.d/20-grubby.install"
    ) 
  ) or
  (process.name == "mv" and process.args == "-f" and process.parent.args == "/usr/sbin/update-initramfs") or
  (
    process.name == "mv" and
    process.parent.args in (
      "/usr/sbin/flash-kernel", "/usr/bin/update-microcode-initrd", "/usr/sbin/update-grub-gfxpayload",
      "/usr/sbin/weak-modules", "/usr/bin/dracut"
    )
  )
)
'''

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

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

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

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

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

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

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

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

[rule]
description = "Identifies when a script interpreter is executed with a long command line and from an unsigned parent executable."
id = "61b8b978-847b-4b1f-9771-b646cde53a9a"
license = "Elastic License v2"
name = "Command and Scripting Interpreter from Suspicious Parent"
os_list = ["windows"]
version = "1.0.6"

query = '''
sequence with maxspan=1m
 [process where event.action == "start" and not user.id : "S-1-5-18" and 
  (
   (process.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk", "USB *") and
    not process.executable : "C:\\*") or

   ((process.Ext.relative_file_creation_time <= 900 or process.Ext.relative_file_name_modify_time <= 900) and
     not process.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and
     not process.executable : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*")) or

   (process.executable :
	        ("?:\\Users\\*\\AppData\\*",
	         "?:\\Users\\*\\Downloads\\*",
	         "?:\\Users\\*\\Desktop\\*",
	         "?:\\Users\\Public\\*") and not process.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*"))
   ) and
  not process.parent.executable : "C:\\Program Files\\Microsoft Visual Studio\\*\\VsDebugConsole.exe"
  ] by process.entity_id
 [process where event.action == "start" and process.name : ("cmd.exe", "powershell.exe") and
  length(process.command_line) >= 200 and not process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and 
  not (process.args : "-InputFormat" and process.args : "-command") and 
  not process.args : "UwB0AGEAcgB0ACAAIgBoAHQAdABw*" and 
  process.command_line : ("*New-ScheduledTaskAction*", "*New-ItemProperty*", "*WScript.Shell*", "*schtasks* /create*", 
                          "*\\Start Menu\\Programs\\*", "*CurrentVersion\\Run*", "*.Invoke(*", "*MpPreference*", 
			  "*-EncodedCommand*", "*Get-Content*", "*Windows Defender*", "*powershell* -e *", "*setZeroData*", 
                          "*Get-Clipboard*", "*http* -xf *", "*dns-query?name=*")
 ] by process.parent.entity_id
'''

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

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

[[optional_actions]]
action = "rollback"
field = "process.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.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

[[threat.technique.subtechnique]]
id = "T1059.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"

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



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

[internal]
min_endpoint_version = "8.4.0"

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

[rule]
author = ["Elastic"]
description = "Identifies command shell activity started via RunDLL32, which is commonly abused by attackers to host malicious code."
false_positives = ["Microsoft Windows installers leveraging RunDLL32 for installation."]
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Command Shell Activity Started via RunDLL32"
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 Command Shell Activity Started via RunDLL32

RunDLL32 is a legitimate Windows utility used to execute functions in DLLs, often leveraged by attackers to run malicious code stealthily. Adversaries exploit it to launch command shells like cmd.exe or PowerShell, bypassing security controls. The detection rule identifies such abuse by monitoring for command shells initiated by RunDLL32, excluding known benign patterns, thus highlighting potential threats.

### Possible investigation steps

- Review the process details to confirm the parent-child relationship between rundll32.exe and the command shell (cmd.exe or powershell.exe) to ensure the alert is not a false positive.
- Examine the command line arguments of rundll32.exe to identify any suspicious or unusual DLLs or functions being executed, excluding known benign patterns.
- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
- Investigate the source and destination network connections associated with the process to identify any suspicious or unauthorized communication.
- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
- Review recent changes or activities on the host, such as software installations or updates, that might explain the execution of rundll32.exe with command shells.

### False positive analysis

- Known false positives include command shells initiated by RunDLL32 for legitimate administrative tasks or software installations.
- Exclude command lines that match common benign patterns, such as those involving SHELL32.dll or temporary files used by trusted applications.
- Regularly update the list of exceptions to include new benign patterns identified through monitoring and analysis.
- Collaborate with IT and security teams to identify and document legitimate use cases of RunDLL32 in your environment.
- Use process monitoring tools to verify the legitimacy of command shells started by RunDLL32, ensuring they align with expected behavior.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as cmd.exe or powershell.exe that were initiated by rundll32.exe to halt potential malicious actions.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
- Review and analyze the rundll32.exe command line arguments to understand the scope and intent of the activity, and identify any additional compromised systems or accounts.
- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access.
- 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 rundll32.exe and related processes to detect similar activities in the future and improve response times."""
risk_score = 21
rule_id = "9ccf3ce0-0057-440a-91f5-870c6ad39093"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
 process.name : ("cmd.exe", "powershell.exe") and
  process.parent.name : "rundll32.exe" and process.parent.command_line != null and
  /* common FPs can be added here */
  not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL",
                             "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc")
'''

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:

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


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

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



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"


[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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[rule.threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"



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

[rule]
description = """
Identifies when a Windows script interpreter loads an external library that allow to call Windows API functions from
scripts in JScript and VBScript. Malware may abuse this legit capability to interact further with the Operating System.
"""
id = "4cd6f758-0057-4e8a-9701-20b6116c2118"
license = "Elastic License v2"
name = "Dynwrapx Image Load via Windows Scripts"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion",
    "https://www.script-coding.com/dynwrapx_eng.html",
    "https://www.splunk.com/en_us/blog/security/detecting-malware-script-loaders-using-remcos-threat-research-release-december-2021.html",
]
version = "1.0.29"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.type == "start" and
  process.name : ("wscript.exe", "cscript.exe", "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe")]
 [library where dll.pe.original_file_name : "dynwrapx.dll"]
'''

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

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

[[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.005"
name = "Visual Basic"
reference = "https://attack.mitre.org/techniques/T1059/005/"

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



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or
non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests
to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application
resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a
successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade
per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC
authentication that fails with error code 700016 (application not found in the directory) where no application display
name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying.
"""
false_positives = [
    """
    A legitimate application that has been deleted from the tenant while a client continues to authenticate against its
    former client ID via ROPC can generate error code 700016. A misconfigured legacy client submitting an incorrect
    client ID is also possible. In both cases the client ID is typically stable and low-volume, unlike the many distinct
    or randomized identifiers seen in spoofing. Verify the application identifier, the source infrastructure, and
    whether the same principal is targeted by many different unresolved client IDs.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID ROPC Authentication with Unknown Client ID"
note = """## Triage and analysis

### Investigating Entra ID ROPC Authentication with Unknown Client ID

Adversaries submit fabricated application identifiers (client IDs) in ROPC authentication requests to Microsoft's token endpoint. Entra ID validates the supplied username and password before rejecting the request because the application does not exist, so the returned error code reveals whether the credential and account are valid without ever producing a successful sign-in. A valid credential paired with a spoofed client ID returns `AADSTS700016` (application not found), an invalid password returns `AADSTS50126`, and a non-existent user returns `AADSTS50034`. Because the application never resolves, application-scoped Conditional Access is bypassed, and fragmenting requests across many random client IDs defeats per-application correlation and rate limiting. This behavior is used for stealthy user enumeration and password spraying (for example, the campaigns Proofpoint tracks as UNK_pyreq2323 and UNK_OutFlareAZ).

This rule detects a ROPC authentication (`authentication_protocol: ropc`) that fails with `status.error_code: 700016` and carries no resolved `app_display_name`, the signature of a spoofed or non-existent client ID. This is a New Terms rule that triggers only when the application identifier (`app_id`) has not been observed in the tenant's sign-in logs in the previous 10 days, so each newly introduced spoofed client ID surfaces once rather than on every attempt.

### Possible investigation steps

- Review `azure.signinlogs.properties.app_id`: the value is a client ID that does not resolve to any registered application in the tenant. Determine whether the same principal or source is presenting many distinct or randomized client IDs (fragmentation) versus a single stable identifier (possible deleted app).
- Assess `azure.signinlogs.properties.user_principal_name`: a valid user account produces a sign-in log for this activity, so the targeted principal exists in the directory and its credentials are being probed. Prioritize privileged or high-value accounts.
- Correlate `azure.signinlogs.properties.status.error_code` for the same user and source over time. A shift from `50126` (invalid password) to `700016` (application not found) for the same account indicates the adversary has confirmed a valid credential, because the request advanced past credential validation.
- Review `source.ip`, `source.as.organization.name`, and `source.geo.country_name`: enumeration commonly originates from hosting providers, VPNs, or proxy infrastructure rather than corporate ranges.
- Inspect `user_agent.original` and `azure.signinlogs.properties.client_app_used`: scripted enumeration frequently uses generic HTTP libraries and logs `client_app_used` as `Unknown`.
- Pivot on the source IP or ASN to determine how many distinct user principals are being probed, which distinguishes targeted probing from broad spraying.

### False positive analysis

- A legitimate application deleted from the tenant while a client keeps authenticating against its former client ID via ROPC can produce `700016`. Such activity is typically a single, stable client ID at low volume, unlike the many distinct or randomized identifiers seen in spoofing.
- A misconfigured legacy client submitting an incorrect client ID may also trigger this rule. Confirm the client ID, the source, and whether the same principal is targeted by multiple unresolved client IDs before dismissing.

### Response and remediation

- If enumeration is confirmed, treat the targeted accounts as credential-probing targets: force password resets and revoke refresh tokens for any account where the error code progressed to `700016` (credential likely validated).
- Block the offending source IPs or ASNs at the firewall, proxy, or via Conditional Access named locations.
- Ensure MFA and Conditional Access are enforced for all user types, and disable legacy and ROPC authentication where not required, since ROPC cannot satisfy MFA.
- Audit targeted accounts for credential reuse across services and monitor for follow-on interactive or non-interactive sign-in success from the same source.
- Notify your identity security team and correlate with any concurrent brute-force or password-spray detections.
"""
references = [
    "https://www.proofpoint.com/us/blog/threat-insight/oauth-client-id-spoofing-why-fake-client-ids-are-gaining-traction-stealthy",
    "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes",
    "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc",
]
risk_score = 47
rule_id = "a222b46e-eba8-492f-a376-b7f5f397a34f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Entra ID",
    "Data Source: Entra ID Sign-in Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs"
    and event.category: "authentication"
    and azure.signinlogs.properties.authentication_protocol: "ropc"
    and azure.signinlogs.properties.status.error_code: 700016
    and not azure.signinlogs.properties.app_display_name: *
'''


[[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.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"
[[rule.threat.technique.subtechnique]]
id = "T1087.004"
name = "Cloud Account"
reference = "https://attack.mitre.org/techniques/T1087/004/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.status.error_code",
    "azure.signinlogs.properties.authentication_protocol",
    "azure.signinlogs.properties.client_app_used",
    "azure.signinlogs.category",
    "source.ip",
    "source.as.organization.name",
    "source.geo.country_name",
    "user_agent.original",
    "event.outcome",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.signinlogs.properties.app_id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[rule]
description = """
Detects when a directory gets created within a temporary directory and a file is created immediately after. This is a
technique that has been observed being used by the most recent Atomic stealer samples in order to organize their data
collection prior to exfiltration.
"""
id = "802d1796-7d9e-4e3c-911b-22281fdfea03"
license = "Elastic License v2"
name = "Exfiltration Data Staging in Temporary Directory via Osascript"
os_list = ["macos"]
version = "1.0.7"

query = '''
sequence with maxspan=10s
[process where event.type == "start" and event.action == "exec" and process.name == "mkdir" and process.args == "-p" and
  process.args like ("/tmp/*", "/private/tmp/*") and
  process.parent.name == "osascript"] by process.parent.entity_id
[file where event.action == "modification" and process.name == "osascript" and file.path like ("/tmp/*", "/private/tmp/*")] by Effective_process.entity_id
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1119"
name = "Automated Collection"
reference = "https://attack.mitre.org/techniques/T1119/"


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

[internal]
min_endpoint_version = "8.11.1"

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

[rule]
author = ["Elastic"]
description = """
Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set
of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM
role to inhibit access to accounts utilized by legitimate users.
"""
false_positives = [
    """
    Role deletions may be done by a system or network administrator. Verify whether the user email, resource name,
    and/or hostname should be making changes in your environment. Role deletions by unfamiliar users or hosts should be
    investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP IAM Role Deletion"
note = """## Triage and analysis

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

### Investigating GCP IAM Role Deletion

Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats.

### Possible investigation steps

- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource.
- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time.
- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations.
- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action.
- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed.

### False positive analysis

- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments.
- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly.
- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening.

### Response and remediation

- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access.
- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access.
- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly.
- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents.
- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/iam/docs/understanding-roles"]
risk_score = 21
rule_id = "e2fb5b18-e33c-4270-851e-c3d675c9afcd"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteRole and event.outcome:success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"


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

[metadata]
creation_date = "2026/07/15"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/07/15"

[rule]
author = ["Elastic"]
description = """
Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including
metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the
GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes
from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code
running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command
is passed to exec.
"""
false_positives = [
    """
    Break-glass debugging from platform engineers may include curl to the metadata IP or hostname.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Pod Exec Cloud Instance Metadata Access"
note = """## Triage and analysis

### Investigating GKE Pod Exec Cloud Instance Metadata Access

This alert fires when a successful pods/exec API call includes a command targeting GKE/GCP instance metadata.
Review `gcp.audit.labels.command.gke.io/command` for the full command string.

### Possible investigation steps

- Confirm the actor (`client.user.email`), source IP, and user agent that performed exec.
- Map `gcp.audit.resource_name` to the target pod/namespace and determine whether the workload should ever call metadata.
- Correlate with GCP audit logs for token issuance or IAM activity around the same time from the node or workload identity.
- Hunt adjacent activity from the same identity: secret reads, additional execs, or RBAC changes.

### False positive analysis

- Approved platform tooling or bootstrap scripts may query metadata during startup; baseline those images and identities.
- Break-glass egress/metadata connectivity tests can match; document and allowlist those principals.

### Response and remediation

- If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that
  could have been read, and tighten pods/exec RBAC plus network policies that deny link-local metadata from pods.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://cloud.google.com/kubernetes-engine/docs/concepts/protecting-cluster-metadata",
]
risk_score = 73
rule_id = "c8bf56cc-c648-4f88-bb4f-9e504d0779d1"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and
event.outcome:success and event.type:start and
event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
gcp.audit.labels.command.gke.io/command:(
  *169.254.169.254* or *metadata.google.internal* or *computeMetadata/v1*
)
'''

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

[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

[[rule.threat.technique.subtechnique]]
id = "T1552.005"
name = "Cloud Instance Metadata API"
reference = "https://attack.mitre.org/techniques/T1552/005/"

[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 = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "event.type",
    "gcp.audit.labels.command.gke.io/command",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

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

[rule]
author = ["Elastic"]
description = """
Detects a two-stage Google Calendar C2 pattern where a scripting runtime (Node.js, Python, osascript) first 
connects to calendar.app.google to retrieve a hidden C2 address, then initiates a secondary connection to the 
decoded C2 host. This sequence is characteristic of packages using Unicode steganography in Google Calendar 
events to stage dynamic command-and-control endpoints.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "Google Calendar C2 via Script Interpreter"
references = [
    "https://www.veracode.com/resources/sophisticated-npm-attack-leveraging-unicode-steganography-and-google-calendar-c2",
    "https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace"
]
risk_score = 73
rule_id = "abc7a2be-479e-428b-b0b3-1d22bda46dd9"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
type = "eql"
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 Google Calendar C2 via Script Interpreter

Threat actors increasingly abuse legitimate cloud services to establish covert command and control channels that blend with normal traffic and bypass traditional network security controls. Google Calendar has been weaponized as a C2 mechanism where attackers store encoded commands in calendar event descriptions, which malware then polls and executes. This detection rule identifies script interpreters connecting to Google Calendar API endpoints, which may indicate this living-off-the-land technique.

### Possible investigation steps

- Review the process.name and process.executable fields to identify which script interpreter is making the Google Calendar API connection and assess whether it is expected for the user or application context.
- Examine the process.command_line and process.args fields to understand what script or code is being executed that initiated the calendar connection.
- Check the process.parent.executable and process.parent.command_line to trace the process lineage and identify how the script interpreter was launched.
- Investigate the Google Workspace audit logs for the associated user account to review calendar events that may contain encoded commands or suspicious content.
- Review network connection details including dns.question.name and destination.ip to understand the specific Google API endpoints being accessed.
- Correlate with authentication events to identify which user account or service account OAuth tokens are being used for the calendar access.
- Search for similar activity across other endpoints to determine if this is an isolated incident or part of a broader campaign.

### False positive analysis

- Legitimate productivity applications may integrate with Google Calendar for scheduling and automation purposes. Verify the application's purpose and whether it is approved by IT.
- Custom automation scripts built by employees may access Google Calendar API for workflow automation. Review with the script owner to confirm legitimacy.
- Development and testing environments may trigger this detection when building calendar integrations. Document known development activities and create targeted exceptions.
- Third-party calendar sync applications may use script interpreters to interface with Google Calendar. Verify these are sanctioned applications.

### Response and remediation

- Immediately terminate the suspicious script interpreter process to stop any ongoing C2 communication.
- Revoke OAuth tokens and API credentials associated with the compromised Google account to prevent further unauthorized access.
- Review Google Workspace admin console for any unauthorized calendar events or modifications that may contain malicious content.
- Isolate the affected macOS system from the network while conducting forensic analysis.
- Perform a comprehensive scan for additional malware, persistence mechanisms, or lateral movement indicators.
- Reset the affected user's credentials and enable multi-factor authentication if not already in place.
- Implement application allowlisting to prevent unauthorized script interpreters from executing.
- Escalate to the security operations team for further investigation into potential data exfiltration or broader compromise.
"""
query = '''
sequence by process.entity_id with maxspan=20s
  [network where host.os.type == "macos" and event.type == "start" and
    (process.name in ("node", "osascript") or process.name like "python*" or
     process.code_signature.trusted == false or process.code_signature.exists == false) and
    destination.domain like "calendar.app.google*"]
  [network where host.os.type == "macos" and event.type == "start" and destination.domain == null]
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1102.001"
name = "Dead Drop Resolver"
reference = "https://attack.mitre.org/techniques/T1102/001/"

[[rule.threat.technique.subtechnique]]
id = "T1102.002"
name = "Bidirectional Communication"
reference = "https://attack.mitre.org/techniques/T1102/002/"

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

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

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

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

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

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

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

[metadata]
creation_date = "2026/05/15"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/15"

[rule]
author = ["Elastic"]
description = """
Detects bursts of Google Workspace device registration events for the same user, where three or more distinct
"google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT"
fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity
typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint
behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay
tooling, both of which mint a new session attestation per relay or replay attempt.
"""
false_positives = [
    """
    A user simultaneously enrolling multiple Workspace-aware apps on a new device (e.g., first-time setup of Gmail,
    Drive, Calendar, and Meet on a new laptop in a short window) may produce three or more distinct device IDs in a
    minute. Validate by checking whether the burst is tied to a fresh device or onboarding event.
    """,
    """
    Major OS upgrades or Workspace client refreshes that re-attest several apps concurrently may also produce a burst.
    Cross-reference against the user's known device OS transitions.
    """,
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Google Workspace Device Registration Burst for Single User"
note = """## Triage and analysis

### Investigating Google Workspace Device Registration Burst for Single User

`DEVICE_REGISTER_UNREGISTER_EVENT` from the Google Workspace `mobile` provider does not represent a one-time physical device enrollment. The Reports API emits a fresh `google_workspace.device.id` on every session/sync registration, and a single physical device can produce multiple events per day as Workspace-aware apps independently attest. Legitimate activity, however, very rarely concentrates three or more distinct device IDs into a one-minute window for a single user. A burst of that shape is the fingerprint of either:

- An AiTM phishing-kit relay session: the kit completes the victim's sign-in against Google, then attests one or more device contexts of its own, all from the same kit infrastructure within seconds.
- Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token.

In both cases the device fingerprint (OS, model) typically converges on a single value distinct from the victim's baseline (e.g., all "Windows" attestations for a known macOS user), and the burst events fire within a few seconds of each other rather than spread across minutes.

### Possible investigation steps

- Identify the user (`user.email`, `user.id`) and inspect `Esql.host_os_version_values`, `Esql.device_type_values`, `Esql.device_model_values`. A homogeneous fingerprint (single OS, single model) across multiple device IDs in the burst window is highly suspicious.
- Cross-reference `logs-google_workspace.login` for `event.action: "login_success"` events from the same `user.email` in the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in's `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for divergence from the user's baseline. Hosting-provider ASNs (Clouvider, Host Telecom, OVH, Alibaba, Vultr, DigitalOcean, M247) for interactive sign-ins are high-fidelity suspicious.
- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events for the same user near the burst window. Each kit relay normally fires a corresponding OAuth grant within seconds, often to Google Chrome (`77185425430.apps.googleusercontent.com`) or another long-lived first-party client.
- Pull all `logs-google_workspace.device` events for the user across the 24 hours preceding the burst to characterize the user's normal device-event rate. A user who typically produces less than 1 event per hour suddenly emitting 3+ in a minute is a strong anomaly even before considering device fingerprints.
- Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window.

### False positive analysis

- New device setup where a user simultaneously enrolls multiple Workspace-aware apps (Gmail, Drive, Calendar, Meet) on first boot can produce a burst. Validate by checking whether the burst coincides with a known device refresh or onboarding event.
- Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition.
- Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts.

### Response and remediation

- Treat as likely AiTM compromise or token-replay activity until proven otherwise. Suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users/<email>/tokens/<clientId>`), reset the password, clear recovery email/phone, sign out all sessions.
- Audit `logs-google_workspace.token: authorize` events for kit-issued or replay-issued OAuth grants. Each grant maps to an independently replayable refresh token; revoking via the consent removes them all at once.
- Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled.
- If the tenant exposes GCP resources to the user, cross-check `logs-gcp.audit-*` for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window; token theft frequently extends to cross-cloud access.
"""
references = [
    "https://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile",
    "https://any.run/malware-trends/tycoon/",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
]
risk_score = 47
rule_id = "bea0589d-c7a4-4dc6-a931-9fecaa8689fb"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Google Workspace",
    "Data Source: Google Workspace Device Logs",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-google_workspace.device-*
| where event.dataset == "google_workspace.device"
    and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT"
    and google_workspace.device.account_state == "REGISTERED"
    and user.email is not null
    and google_workspace.device.id is not null

| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp)

| stats
        Esql.count_distinct_device_id = count_distinct(google_workspace.device.id),
        Esql.device_id_values = values(google_workspace.device.id),
        Esql.device_resource_id_values = values(google_workspace.device.resource.id),
        Esql.device_type_values = values(google_workspace.device.type),
        Esql.device_model_values = values(google_workspace.device.model),
        Esql.device_account_state_values = values(google_workspace.device.account_state),
        Esql.host_os_version_values = values(host.os.version),
        Esql.event_provider_values = values(event.provider),
        Esql.event_id_values = values(event.id),
        Esql.google_workspace_actor_type_values = values(google_workspace.actor.type),
        Esql.google_workspace_event_type_values = values(google_workspace.event.type),
        Esql.organization_id_values = values(organization.id),
        Esql.user_domain_values = values(user.domain),
        Esql.timestamp_first_seen = min(@timestamp),
        Esql.timestamp_last_seen = max(@timestamp),
        Esql.event_count = count(*)
    by user.id, user.email, user.name, Esql.bucket_minute

| where Esql.count_distinct_device_id >= 3

| keep user.id,
        user.email,
        user.name,
        Esql.bucket_minute,
        Esql.timestamp_first_seen,
        Esql.timestamp_last_seen,
        Esql.count_distinct_device_id,
        Esql.event_count,
        Esql.device_id_values,
        Esql.device_resource_id_values,
        Esql.device_type_values,
        Esql.device_model_values,
        Esql.device_account_state_values,
        Esql.host_os_version_values,
        Esql.event_provider_values,
        Esql.event_id_values,
        Esql.google_workspace_actor_type_values,
        Esql.google_workspace_event_type_values,
        Esql.organization_id_values,
        Esql.user_domain_values
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"



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



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"


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

[rule.investigation_fields]
field_names = ["@timestamp", "user.email", "user.id", "user.name"]

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

[rule]
author = ["Elastic"]
description = """
The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first
point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic
to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or
RHEL) and macOS systems.
"""
from = "now-9m"
index = ["auditbeat-*", "winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
language = "eql"
license = "Elastic License v2"
name = "Hosts File Modified"
note = """## Triage and analysis

### Investigating Hosts File Modified

Operating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to "Fail open" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this [CISA Alert](https://www.cisa.gov/uscert/ncas/alerts/aa22-074a).

This rule identifies modifications in the hosts file across multiple operating systems using process creation events for Linux and file events in Windows and macOS.

#### Possible investigation steps

- Identify the specifics of the involved assets, such as role, criticality, and associated users.
- 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.
- Examine the changes to the hosts file by comparing it against file backups, volume shadow copies, and other restoration mechanisms.

### False positive analysis

- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and the configuration was justified.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Consider isolating 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.
- Review the privileges of the administrator account that performed the action.
- 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).
"""
references = ["https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-reference-yml.html"]
risk_score = 47
rule_id = "9c260313-c811-4ec8-ab89-8f6530e0246c"
setup = """## Setup

For Windows systems using Auditbeat, this rule requires adding `C:/Windows/System32/drivers/etc` as an additional path in the 'file_integrity' module of auditbeat.yml.

If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
`event.ingested` to @timestamp.
For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
]
timeline_id = "4d4c0b59-ea83-483f-b8c1-8c360ee53c5c"
timeline_title = "Comprehensive File Timeline"
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where process.executable != null and

  /* file events for creation; file change events are not captured by some of the included sources for linux and so may
     miss this, which is the purpose of the process + command line args logic below */
  (
   event.category == "file" and event.type in ("change", "creation") and event.action != "rename" and
     file.path : ("/private/etc/hosts", "/etc/hosts", "?:\\Windows\\System32\\drivers\\etc\\hosts") and 
     not process.name in ("dockerd", "rootlesskit", "podman", "crio") and
     not process.executable : ("C:\\Program Files\\Fortinet\\FortiClient\\FCDBLog.exe",
                               "C:\\Program Files\\Fortinet\\FortiClient\\FortiWF.exe",
                               "C:\\Program Files\\Fortinet\\FortiClient\\fmon.exe",
                               "C:\\Program Files\\Seqrite\\Seqrite\\SCANNER.EXE",
                               "C:\\Windows\\System32\\SearchProtocolHost.exe",
                               "C:\\Windows\\Temp\\*.ins\\inst.exe",
                               "C:\\Windows\\System32\\svchost.exe",
                               "C:\\Program Files\\NordVPN\\nordvpn-service.exe",
                               "C:\\Program Files\\Tailscale\\tailscaled.exe",
                               "C:\\Program Files\\Docker\\Docker\\com.docker.service",
                               "C:\\Program Files\\Docker\\Docker\\InstallerCli.exe",
                               "C:\\Program Files\\Quick Heal\\Quick Heal AntiVirus Pro\\scanner.exe",
                               "C:\\Program Files (x86)\\Quick Heal AntiVirus Pro\\SCANNER.EXE",
                               "C:\\Program Files\\Quick Heal\\Quick Heal Internet Security\\scanner.exe",
                               "C:\\Program Files (x86)\\Cisco\\Cisco AnyConnect Secure Mobility Client\\vpnagent.exe",
                               "/Applications/Parallels Desktop.app/Contents/MacOS/prl_naptd",
                               "/opt/IBM/InformationServer/Server/DSEngine/bin/uvsh",
                               "/usr/local/demisto/server", 
                               "/usr/local/bin/defender")
  )
  or

  /* process events for change targeting linux only */
  (
   event.category == "process" and event.type in ("start") and
     process.name in ("nano", "vim", "vi", "emacs", "echo", "sed") and
     (process.args : ("/etc/hosts") or (process.working_directory == "/etc" and process.args == "hosts")) and 
     not process.parent.name in ("dhclient-script", "google_set_hostname") and
     not process.command_line == "sed -i /Added by Google/d /etc/hosts"
  )
'''


[[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/07/24"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/08/10"

[rule]
author = ["Elastic"]
description = """
Identifies potential relay activities against a Computer account by identifying authentication events using the computer
account coming from from hosts other than the server that owns the account. Attackers may relay the computer account
hash after capturing it using forced authentication.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Computer Account NTLM Relay Activity"
note = """## Triage and analysis

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

### Investigating Potential Computer Account NTLM Relay Activity

### Possible investigation steps

- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account.
- Examine the source.ip activities as this is the attacker IP address used to relay.
- Review all relevant activities such as services creation, file and process events on the target server within the same period.
- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.
- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.
- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.
- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.

### False positive analysis

- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.
- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.
- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.
- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.
- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
    - If the involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed.
- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.
- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems.
- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems.
- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response.
- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity.
- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future.
"""

setup = """## Setup

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""

references = [
    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
    "https://attack.mitre.org/techniques/T1187/",
]
risk_score = 47
rule_id = "263481c8-1e9b-492e-912d-d1760707f810"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Active Directory",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
 winlog.logon.type == "Network" and winlog.event_data.AuthenticationPackageName == "NTLM" and
 endswith~(user.name, "$") and user.name != "$" and
 source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" and

 /* Filter for a machine account that matches the hostname */
 startswith~(host.name, substring(user.name, 0, -1)) and

 /* Verify the machine account matches the full hostname, not just a prefix substring */
 (startswith~(substring(user.name, 0, -1), host.name) or startswith~(host.name, concat(substring(user.name, 0, -1), "."))) and

 /* Verify if the Source IP belongs to the host */
 not endswith(string(source.ip), string(host.ip)) and
 indexOf(string(host.ip), string(source.ip)) == null and

 /* Exclude self-authentication from multi-homed hosts where the NTLM workstation name matches the machine account */
 not (source.domain != null and
      startswith~(user.name, source.domain) and
      startswith~(source.domain, substring(user.name, 0, -1)))
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1187"
name = "Forced Authentication"
reference = "https://attack.mitre.org/techniques/T1187/"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"
[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"



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

[metadata]
creation_date = "2025/06/18"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/04/22"

[rule]
author = ["Elastic"]
description = """
Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target
server's computer account, originating from a different host. This may indicate that an attacker has captured and
relayed Kerberos authentication material for the server's computer account to execute code on behalf of the
compromised system.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Kerberos Relay Attack against a Computer Account"
references = [
    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
    "https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025",
    "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
    "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
    "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
    "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
]
risk_score = 73
rule_id = "2d58f67c-156e-480a-a6eb-a698fd8197ff"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Active Directory",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by winlog.computer_name, source.ip with maxspan=5s

/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */
[file where host.os.type == "windows" and event.code : "5145" and 
    not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
    file.name : (
        "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc",
        "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe"
    )]

/* Detects a logon attempt using the Kerberos protocol resulting from the coercion coming from the same IP address */
[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
    endswith~(user.name, "$") and winlog.logon.type : "network" and
    winlog.event_data.AuthenticationPackageName : "Kerberos" and

    /* Filter for a machine account that matches the hostname */
    startswith~(winlog.computer_name, substring(user.name, 0, -1)) and

    /* Verify if the Source IP belongs to the host */
    not endswith(string(source.ip), string(host.ip)) and
    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]
'''

note = """## Triage and analysis

### Investigating Potential Kerberos Relay Attack against a Computer Account

#### Possible investigation steps

- What do the recovered source events prove about the relay sequence?
  - Why: Kerberos relay can reuse a coerced machine-account ticket when SPN selection or service protections allow it; reflective variants keep the same triage anchors: recovered pipe, `source.ip`, target dollar account, and Kerberos network auth.
  - Hint: Open Investigate in Timeline before interpreting the grouped alert; filter the alert window to `event.code` 5145 and 4624/4625 with the same `winlog.computer_name` and `source.ip`. In this step, read `file.name` from the recovered 5145 source event. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation. Treat it as optional corroboration, not the alert source.
  - Focus: recovered 5145 and 4624/4625 source events scoped by `winlog.computer_name`, `source.ip`, and `@timestamp`; in the 5145 event read `file.name` as the named-pipe value, then in the auth event read `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `host.ip`.
  - Implication: escalate when a known coercion pipe such as Spoolss, netdfs, lsarpc, efsrpc, netlogon, srvsvc, or winreg is followed within seconds by a Kerberos network logon from the same non-target `source.ip`; lower suspicion only when the recovered pipe/auth outcome recurs for the same source, server, and machine account and outside topology or owner evidence verifies that exact infrastructure role.

- Does the authenticated machine account belong to the target server?
  - Focus: `winlog.event_data.TargetUserName` dollar-account prefix and `winlog.event_data.TargetDomainName` from the auth source event compared with `winlog.computer_name`.
  - Implication: escalate when the target account is the target server's dollar account and the source is not the server itself; if the account does not map to the target server, resolve whether the sequence paired unrelated events before using the alert for closure or escalation.

- Did the Kerberos authentication create a usable session or only a failed attempt?
  - Focus: auth source-event `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.TargetLogonId`, and `source.ip`.
  - Implication: prioritize confirmed compromise review when a 4624 produces a `winlog.event_data.TargetLogonId`; keep failed-only 4625 sequences suspicious when the source or pipe is unexplained, but lower urgency when the status pattern is a recurring, bounded failure from recognized infrastructure.

- Does the source IP fit recognized infrastructure or relay-characteristic behavior?
  - Focus: surrounding Windows Security authentication events for `source.ip` and `winlog.computer_name`, reading `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
  - Hint: use same-source authentication events to see whether the source targets multiple machine accounts or alternates Kerberos successes and failures around the alert. $investigate_2
  - Implication: escalate when the source is rare for this server, targets multiple machine accounts, or alternates Kerberos successes and failures outside a verified infrastructure role; missing surrounding authentication telemetry is unresolved, not benign. Lower suspicion only when the same bounded source/server/account/outcome pattern recurs and outside topology or owner evidence verifies the exact role.

- If local evidence is suspicious or unresolved, is this part of broader relay activity?
  - Focus: related alerts for `source.ip` that show additional coercion or machine-account Kerberos relay. $investigate_0
  - Hint: pivot target-server related alerts for service creation, persistence, or remote execution only when the source pivot is suspicious; missing related alerts narrows existing-alert scope only, not host activity. $investigate_1
  - Hint: for raw Windows Security scoping after a 4624, review follow-on Windows Security events on the same `winlog.computer_name` where `winlog.event_data.SubjectLogonId` matches the recovered `winlog.event_data.TargetLogonId`; filter within results for service creation, task creation, share access, or persistence if the result set is large. Missing follow-on events is unresolved unless that event coverage is confirmed. $investigate_3
  - Implication: expand scope when source history shows other coercion or machine-account Kerberos relay, or when target history shows follow-on service, persistence, or remote-execution alerts; keep containment local only when related alerts stay limited to the same explained infrastructure tuple.

- Based on the recovered evidence, what disposition is supported?
  - Focus: sequence integrity, target dollar-account identity, Kerberos outcome, source-fit tuple, and related-alert results.
  - Implication: escalate when the sequence is intact and unexplained, when successful machine-account Kerberos comes from an unrecognized source, or when related-alert evidence shows follow-on abuse; close only when recovered source events and supported recovery bind one exact recognized infrastructure workflow with no contradictory evidence; preserve and escalate when evidence conflicts or visibility is missing.

### False positive analysis

- Validated infrastructure peers or authorized relay/coercion testing are the narrow benign paths. Confirm by verifying the recovered source events align on the same `source.ip`, `winlog.computer_name`, target machine account in `winlog.event_data.TargetUserName`, Kerberos `winlog.event_data.AuthenticationPackageName`, network `winlog.logon.type`, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence for the same server/account/pipe/outcome tuple. If telemetry cannot explain the specific pipe, account, and outcome, do not close as benign.
- Use topology, owner, or test-plan confirmation only to verify the exact recovered tuple after source-event recovery. Before creating an exception, validate recurrence across prior alerts from this rule for the same source/server/account/pipe/outcome pattern. If this is the first confirmed benign occurrence, document it as a candidate exception and monitor before suppressing. Build exceptions from the full confirmed workflow pattern; avoid exceptions on `source.ip`, `winlog.computer_name`, or machine-account name alone.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the evidence that proved the workflow: `source.ip`, `winlog.computer_name`, target machine account, Kerberos network auth, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence. Create an exception only after the same full pattern recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before containment. Use reversible containment first: temporarily restrict SMB/RPC between `source.ip` and the affected server, or isolate the source host when its role tolerates isolation. Escalate to broader host or account action only if follow-on service, persistence, execution, or wider relay evidence appears.
- If confirmed malicious, preserve the same alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before action. Then contain the source host and restrict access to the affected `winlog.computer_name`; if direct containment is unavailable, hand off the preserved evidence set to the team that can act. Remove the coercion route, block the offending source path, and eradicate only services, scheduled tasks, dropped tools, or configuration changes confirmed during response.
- Rotate the affected computer-account secret and review adjacent delegated, service, or administrative credentials that could have been exposed through the relay path. Coordinate disruptive credential or host actions with identity and infrastructure owners when the target is a domain controller, cluster node, or other critical service.
- After containment, audit other servers reached from the same `source.ip` and retain Windows Security source events needed to reconstruct each source/server/account/pipe sequence.
- Post-incident hardening: before releasing containment for a reflective Kerberos relay path, validate the relevant CVE-2025-33073 fixes and SMB signing or service-specific signing/sealing/channel binding on the affected service tier. Restrict coercion-prone RPC and named-pipe exposure, then document the confirmed source/server/account/pipe pattern for future analysts and control owners.
"""

setup = """## Setup

The following Windows audit policies must be enabled to generate the events used by this rule:
- [Audit Logon](https://ela.st/audit-logon)
- [Audit Detailed File Share](https://ela.st/audit-detailed-file-share)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.code",
    "winlog.computer_name",
    "source.ip",
    "host.ip",
    "user.name",
    "file.name",
    "winlog.event_data.TargetUserName",
    "winlog.event_data.TargetDomainName",
    "winlog.event_data.AuthenticationPackageName",
    "winlog.logon.type",
    "winlog.event_data.Status",
    "winlog.event_data.SubStatus",
    "winlog.event_data.TargetLogonId",
    "winlog.event_data.SubjectLogonId",
]

[[transform.investigate]]
label = "Alerts associated with this source IP"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with this target server"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Authentication events from this source to this target"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
    { excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "Kerberos", valueType = "string" }
  ],
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" },
    { excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "Kerberos", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Follow-on Windows Security events for the Kerberos logon session"
description = ""
providers = [
  [
    { excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.TargetLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1187"
name = "Forced Authentication"
reference = "https://attack.mitre.org/techniques/T1187/"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"

[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"

[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 = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"