Elastic rules: 1o

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

[rule]
author = ["Elastic"]
description = """
Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period.
This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or
prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster
recovery capabilities, making it a critical indicator of potentially malicious activity.
"""
false_positives = [
    """
    Infrastructure teams may legitimately delete multiple snapshots during planned maintenance, storage optimization, or
    cleanup of expired backup data according to retention policies. Verify that the deletion activity was expected and
    follows organizational change management processes. Consider exceptions for approved maintenance windows or
    automation service principals managing backup retention.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Compute Snapshot Deletions by User"
note = """## Triage and analysis

### Investigating Azure Compute Snapshot Deletions by User

Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities.
- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization.
- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal.
- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions.
- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal.
- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
- Determine if any remaining snapshots or alternative backups exist for the affected resources.

### False positive analysis

- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules.
- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows.
- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods.
- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines.

### Response and remediation

- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders.
- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms.
- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy.
- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions.
- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement.
- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion.
- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations.
- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted.
- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies.
- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise.
- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
"""
references = [
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 47
rule_id = "d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Storage",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset: azure.activitylogs and
    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
    azure.activitylogs.properties.status_code: "Accepted" and
    azure.activitylogs.identity.claims_initiated_by_user.name: *
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "azure.activitylogs.identity.claims_initiated_by_user.name",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
    "azure.activitylogs.identity.claims.appid",
    "azure.activitylogs.identity.claims.sid",
    "azure.resource.name",
    "azure.resource.group",
    "azure.activitylogs.operation_name",
    "azure.subscription_id",
    "azure.activitylogs.tenant_id",
    "source.ip",
]


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

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


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

[rule.threshold]
field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
value = 1
[[rule.threshold.cardinality]]
field = "azure.resource.name"
value = 3

[metadata]
creation_date = "2021/01/19"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/16"

[rule]
author = ["Elastic"]
description = """
Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files
are executed in a user's context, either interactively or non-interactively, when a user logs in so that their
environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content
triggered by a user’s shell.
"""
false_positives = ["Changes to the Shell Profile tend to be noisy, a tuning per your environment will be required."]
from = "now-9m"
index = ["logs-endpoint.events.file-*", "auditbeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Bash Shell Profile Modification"
references = ["https://www.anomali.com/blog/pulling-linux-rabbit-rabbot-malware-out-of-a-hat"]
risk_score = 47
rule_id = "e6c1a552-7776-44ad-ae0f-8746cc07773c"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.category:file and host.os.type:(linux or macos) and event.type:change and not event.action:("rename" or "extended_attributes_delete") and
  file.name:(".bash_profile" or ".profile" or ".bashrc" or ".zshenv" or ".zshrc") and file.path:(/home/* or /Users/*) and 
  process.name:(* and not (sudo or vim or zsh or env or nano or bash or Terminal or xpcproxy or login or cat or cp or
  launchctl or java or dnf or tailwatchd or ldconfig or yum or semodule or cpanellogd or dockerd or authselect or chmod or
  dnf-automatic or git or dpkg or platform-python)) and
  not process.executable:(/Applications/* or /private/var/folders/* or /usr/local/* or /opt/saltstack/salt/bin/*)
'''
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 Bash Shell Profile Modification

Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these by inserting malicious commands to ensure persistence, executing harmful scripts whenever a user initiates a shell session. The detection rule identifies unauthorized modifications by monitoring file changes and filtering out benign processes, focusing on unusual executables and paths to flag potential threats.

### Possible investigation steps

- Review the alert details to identify the specific file path that was modified, focusing on paths like /home/*/.bash_profile or /home/*/.bashrc.
- Examine the process name and executable that triggered the alert to determine if it is an unusual or unauthorized process, as specified in the query.
- Check the modification timestamp of the affected file to correlate with any known user activity or scheduled tasks.
- Investigate the contents of the modified Bash shell profile file to identify any suspicious or unexpected commands or scripts.
- Cross-reference the user account associated with the modified file to determine if the activity aligns with their typical behavior or if the account may be compromised.
- Look for any related alerts or logs around the same timeframe that might indicate a broader attack or persistence mechanism.

### False positive analysis

- Frequent use of text editors like vim or nano may trigger alerts when users legitimately modify their shell profiles. To mitigate this, consider excluding these processes from the detection rule if they are commonly used in your environment.
- Automated system updates or configuration management tools like dnf or yum might modify shell profiles as part of their operations. Exclude these processes if they are verified as part of routine maintenance.
- Development tools such as git or platform-python may alter shell profiles during setup or updates. If these tools are regularly used, add them to the exclusion list to prevent false positives.
- User-specific applications located in directories like /Applications or /usr/local may be flagged if they modify shell profiles. Verify these applications and exclude their paths if they are trusted and frequently used.
- Consider excluding specific user directories from monitoring if they are known to contain benign scripts that modify shell profiles, ensuring these exclusions are well-documented and reviewed regularly.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified in the alert that are not part of the allowed list, such as unauthorized executables modifying shell profiles.
- Restore the modified shell profile files (.bash_profile, .bashrc) from a known good backup to remove any malicious entries.
- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
- Implement file integrity monitoring on critical shell profile files to detect and alert on future unauthorized changes.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Review and update endpoint protection policies to enhance detection capabilities for similar persistence techniques, leveraging MITRE ATT&CK framework references for T1546."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.004"
name = "Unix Shell Configuration Modification"
reference = "https://attack.mitre.org/techniques/T1546/004/"



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

[rule]
description = """
Identifies the execution of Windows commands to open a file originating from an unknown remote source. Adversaries may
embed malicious files in a shortcut file before delivering it to their target in order to trick them into executing the
payload.
"""
id = "9287bf52-d1d8-499e-a135-a64645da6870"
license = "Elastic License v2"
name = "Command Shell Execution from Untrusted Origin"
os_list = ["windows"]
reference = [
    "https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview",
]
version = "1.0.2"

query = '''
process where event.action == "start" and
 process.name : ("cmd.exe", "powershell.exe") and process.parent.name : "explorer.exe" and
 process.Ext.token.security_attributes : "SMARTLOCKER://SMARTSCREENORIGINCLAIM" and
 process.parent.thread.Ext.call_stack_summary : "ntdll.dll|kernelbase.dll|kernel32.dll|windows.storage.dll|shell32.dll|windows.storage.dll|shell32.dll*" and
 not process.parent.thread.Ext.call_stack_summary : ("*coremessagingxp.dll*", "*ExplorerFrame.dll*") and process.args_count >= 2 and
 process.working_directory :
                 ("C:\\Windows\\System32\\*",
                  "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*",
                  "?:\\Users\\*\\AppData\\Local\\Temp\\7z*",
                  "?:\\Users\\*\\Content.Outlook\\*",
                  "?:\\Users\\*\\Downloads\\*") and
  not (process.name : "cmd.exe" and
       process.command_line : ("*\\AppData\\Local\\Microsoft\\OneDrive\\*", "*.bat*", "*.cmd*",
       "*reg.exe delete HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v Bomgar_Cleanup*")) and
  not (process.name : "powershell.exe" and
       process.args : ("*-file*", "*.ps1*", "*.xml*", "*Remove-AppxPackage*", "*Get-AppxPackage*", "*Remove-ItemProperty*"))
'''

min_endpoint_version = "8.10.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

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

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

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



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[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]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.001"
name = "Malicious Link"
reference = "https://attack.mitre.org/techniques/T1204/001/"



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

[internal]
min_endpoint_version = "8.10.0"

[rule]
description = """
Detects the execution of curl via osascript with the "-o" argument indicating a file download. This activity should be
highly abnormal and considered suspicious at least. Threat actors have consistently been seen utilizing this technique
to establish C2 or download additional payloads / tools.
"""
id = "883cbfd8-278a-403c-907a-aefb02da0429"
license = "Elastic License v2"
name = "Curl Executable File Download via Osascript"
os_list = ["macos"]
version = "1.0.15"

query = '''
file where event.action == "modification" and file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*") and
 process.name in ("curl", "nscurl") and Effective_process.name == "osascript"
'''

min_endpoint_version = "8.10.2"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 0

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

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


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

[internal]
min_endpoint_version = "8.10.2"

[rule]
description = """
Detects when curl is executed with the -o option and the effective parent process is an Apple installer process. Threat
actors will utilize benign or backdoored software packages to download second stage payloads using curl in order to
avoid detection and gain malicious code execution. An example of this activity is the nation state malware known as
oRAT.
"""
id = "a4a66e7f-b81a-4a2c-8f33-28a6807314a9"
license = "Elastic License v2"
name = "Curl Execution via Apple Installer Package"
os_list = ["macos"]
version = "1.0.13"

query = '''
process where event.type == "start" and 
  process.name in ("curl", "nscurl") and process.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory") and
  process.Ext.effective_parent.name in ("installer", "package_script_service") and
  not process.args like ("https://agents.addigy.com/*", "https://pkg.devkitpro.org/packages/*")
'''

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

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

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


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

[internal]
min_endpoint_version = "8.5.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often
observed during malware installation and is consistent with an attacker attempting to evade detection.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Delayed Execution via Ping"
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 Delayed Execution via Ping

Ping, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes.

### Possible investigation steps

- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe.
- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior.
- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused.
- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious.
- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed.
- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity.

### False positive analysis

- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe.
- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures.
- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list.
- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths.
- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise.

### Response and remediation

- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software.
- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems.
- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question.
- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
risk_score = 21
rule_id = "e00b8d49-632f-4dc6-94a5-76153a481915"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by process.parent.entity_id with maxspan=1m
  [process where host.os.type == "windows" and event.action == "start" and process.name : "ping.exe" and
   process.args : "-n" and process.parent.name : "cmd.exe" and not user.id : "S-1-5-18"]
  [process where host.os.type == "windows" and event.action == "start" and
   process.parent.name : "cmd.exe" and
   (
        process.name : (
            "rundll32.exe", "powershell.exe",
            "mshta.exe", "msbuild.exe",
            "certutil.exe", "regsvr32.exe",
            "powershell.exe", "cscript.exe",
            "wscript.exe", "wmic.exe",
            "installutil.exe", "msxsl.exe",
            "Microsoft.Workflow.Compiler.exe",
            "ieexec.exe", "iexpress.exe",
            "RegAsm.exe", "installutil.exe",
            "RegSvcs.exe", "RegAsm.exe"
        ) or
        (process.executable : "?:\\Users\\*\\AppData\\*.exe" and not process.code_signature.trusted == true)
    ) and

    not process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and
    not (process.name : ("openssl.exe", "httpcfg.exe", "certutil.exe") and process.parent.command_line : "*ScreenConnectConfigurator.cmd*") and
    not (process.pe.original_file_name : "DPInst.exe" and process.command_line : "driver\\DPInst_x64  /f ") and
    not (process.name : "powershell.exe" and process.args : "Write-Host ======*") and
    not (process.name : "wscript.exe" and process.args : "launchquiet_args.vbs" and process.parent.args : "?:\\Windows\\TempInst\\7z*") and
    not (process.name : "regsvr32.exe" and process.args : ("?:\\windows\\syswow64\\msxml?.dll", "msxml?.dll", "?:\\Windows\\SysWOW64\\mschrt20.ocx")) and
    not (process.name : "wscript.exe" and
         process.working_directory :
                    ("?:\\Windows\\TempInst\\*",
                     "?:\\Users\\*\\AppData\\Local\\Temp\\BackupBootstrapper\\Logs\\",
                     "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\"))
    ]
'''

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


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

[[rule.threat.technique]]
id = "T1047"
name = "Windows Management Instrumentation"
reference = "https://attack.mitre.org/techniques/T1047/"

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

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

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

[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"

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

[[rule.threat.technique]]
id = "T1216"
name = "System Script Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1216/"

[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

[[rule.threat.technique.subtechnique]]
id = "T1218.003"
name = "CMSTP"
reference = "https://attack.mitre.org/techniques/T1218/003/"

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

[[rule.threat.technique.subtechnique]]
id = "T1218.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"

[[rule.threat.technique.subtechnique]]
id = "T1218.009"
name = "Regsvcs/Regasm"
reference = "https://attack.mitre.org/techniques/T1218/009/"

[[rule.threat.technique.subtechnique]]
id = "T1218.010"
name = "Regsvr32"
reference = "https://attack.mitre.org/techniques/T1218/010/"

[[rule.threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"

[[rule.threat.technique]]
id = "T1220"
name = "XSL Script Processing"
reference = "https://attack.mitre.org/techniques/T1220/"

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

[[rule.threat.technique.subtechnique]]
id = "T1497.003"
name = "Time Based Checks"
reference = "https://attack.mitre.org/techniques/T1497/003/"

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

[rule]
description = """
Identifies the creation of a driver file by an untrusted program and subsequently loaded in the kernel. Adversaries may
bring a driver onto a compromised machine to execute code with the highest privileges.
"""
id = "3f1cbf09-dba1-428d-8c84-a86db573889e"
license = "Elastic License v2"
name = "Driver Dropped by Untrusted Executable"
os_list = ["windows"]
reference = ["https://www.elastic.co/security-labs/forget-vulnerable-drivers-admin-is-all-you-need"]
version = "1.0.35"

query = '''
sequence with maxspan=5m 
 [process where event.action == "start" and 
  (process.code_signature.trusted == false or process.code_signature.exists == false) and 
  (process.Ext.relative_file_creation_time <= 3600 or process.Ext.relative_file_name_modify_time <= 500) and
  process.hash.sha256 != "bb3468b6c88b0553d039ec3c4e6a13aa9ce500d6962ca906dfda57b7deafcfa9"] as event0
 [file where event.action != "deletion" and
  (file.extension : "sys" or file.Ext.header_bytes : "4d5a*") and 
   process.entity_id == event0.process.entity_id and 
  (process.code_signature.trusted == false or process.code_signature.exists == false)] as event1
 [library where process.pid == 4 and 
  startswith~(dll.path, event1.file.path) and 
  not (dll.code_signature.subject_name : ("FinalWire Kft.", "Musaruba US LLC") and dll.code_signature.trusted == true)]
'''

min_endpoint_version = "8.10.0"
reputation = true
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

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



[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1014"
name = "Rootkit"
reference = "https://attack.mitre.org/techniques/T1014/"


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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2026/03/03"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API.
Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and
configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can
forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access
policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for
persistent, stealthy access to victim tenants.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Domain Federation Configuration Change"
note = """## Triage and analysis

### Investigating Entra ID Domain Federation Configuration Change

This rule detects when domain federation settings are added or modified in an Entra ID tenant. Domain federation allows organizations to delegate authentication for a UPN domain suffix to an external Identity Provider (IdP). While this is a legitimate feature for organizations using external IdPs like Okta or ADFS, adversaries can abuse it to establish persistent access by federating a domain to an attacker-controlled IdP.

This is the highest blast radius federation abuse technique, unlike app-level federated identity credentials (which affect a single service principal), domain federation affects all users whose UPN matches the federated domain.

Both events share the same `correlation_id` but neither includes the federation configuration details (issuer URI, signing certificate) in the event properties.

### Possible investigation steps

- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
- For `"Set domain authentication"` events, check `azure.auditlogs.properties.target_resources.0.display_name` to identify which domain was federated.
- Use `azure.correlation_id` to correlate the companion `"Set federation settings on domain"` event and establish the full context.
- Query the Graph API to retrieve the actual federation configuration details, since they are not logged in the audit event: `Get-MgDomainFederationConfiguration -DomainId "<domain>"`.
- Review the configured issuer URI and signing certificate to determine if the external IdP is legitimate or attacker-controlled.
- Check for precursor events with the same actor: `"Add unverified domain"` and `"Verify domain"` events targeting the same domain would indicate the full attack chain.
- Review Azure sign-in logs for any authentication activity from users under the newly federated domain.
- Investigate whether the domain was recently added to the tenant or was a pre-existing domain whose authentication type was changed.
- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action.

### False positive analysis

- Legitimate domain federation changes by IT administrators during initial tenant setup or IdP migrations (e.g., migrating from ADFS to Okta).
- Organizational restructuring such as mergers or acquisitions where new domains are federated.
- Scheduled maintenance or updates to federation certificates or IdP endpoints.
- Validate with the Global Administrator or identity team before dismissing.

### Response and remediation

- If the federation change is unauthorized, immediately remove the federation configuration: `Remove-MgDomainFederationConfiguration -DomainId "<domain>" -InternalDomainFederationId "<id>"`.
- Revert the domain authentication type to managed if it should not be federated.
- Revoke all active sessions and tokens for users under the affected domain.
- Audit recent sign-in activity for users under the federated domain to identify unauthorized access.
- Investigate how the adversary obtained Global Administrator privileges to perform this action.
- Review and restrict who has Domain Administrator or Global Administrator roles using PIM (Privileged Identity Management).
- Implement alerts on domain management operations and restrict domain federation changes via conditional access policies.
"""
references = [
    "https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29",
    "https://learn.microsoft.com/en-us/graph/api/domain-post-federationconfiguration",
    "https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360",
    "https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/",
    "https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864",
]
risk_score = 73
rule_id = "1cfb39e1-4b6c-4dc7-85fe-733e4a1a33ca"
setup = """### Microsoft Entra ID Audit Logs
This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: azure.auditlogs
    and azure.auditlogs.properties.category: DirectoryManagement
    and event.action: ("Set domain authentication" or "Set federation settings on domain")
    and event.outcome: success
'''


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

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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.001"
name = "Additional Cloud Credentials"
reference = "https://attack.mitre.org/techniques/T1098/001/"

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

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

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

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

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

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

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

[metadata]
creation_date = "2026/05/20"
integration = ["azure"]
maturity = "production"
updated_date = "2026/05/20"

[rule]
author = ["Elastic", "descambiado"]
description = """
Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation.
A Guest-to-Member conversion grants the account full directory read access, removes external-identity
Conditional Access restrictions, and makes the account indistinguishable from an internal employee.
An attacker who compromises a guest account and promotes it to Member type gains persistent tenant
access without triggering role assignment alerts.
"""
false_positives = [
    """
    B2B collaboration migrations where external users are intentionally promoted to full membership.
    Organizational restructuring that converts former contractors to permanent employees in place.
    """,
]
from = "now-9m"
index = ["logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Guest Account Promoted to Member"
note = """## Triage and analysis

### Investigating Entra ID Guest Account Promoted to Member

A Guest-to-Member UserType conversion is a rarely needed, high-impact operation that removes all
guest account restrictions. In most tenants it occurs fewer than once per month.

#### Possible investigation steps

- Identify the administrator who performed the conversion (`azure.auditlogs.properties.initiated_by`)
  and verify whether the action was authorized.
- Check when the guest account was originally invited: look for "Invite external user" in AuditLogs
  with the same target object ID.
- Review post-conversion sign-in activity in `azure.signinlogs.*` for the target account -- look for
  directory enumeration patterns (access to Graph API `/users`, `/groups`, `/applications`).
- Check whether the converting actor's role was recently granted and whether other high-privilege
  operations were performed around the same time.

### False positive analysis

- Planned B2B-to-member migrations coordinated by HR or IT should be documented in change records.
  Confirm via ticket correlation before closing.

### Response and remediation

- Revert the UserType to Guest if unauthorized: Entra ID > Users > Edit properties.
- Revoke all sessions for the affected account.
- Review all directory objects the account accessed after the conversion.
"""
references = [
    "https://learn.microsoft.com/en-us/entra/external-id/user-properties",
    "https://learn.microsoft.com/en-us/entra/identity/users/convert-external-users-internal",
]
risk_score = 47
rule_id = "30090d40-cdfd-4750-a281-0125fdf22045"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "azure.auditlogs" and
azure.auditlogs.operation_name: "Update user" and
azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "UserType" and
azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value: *Guest* and
azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: *Member* and
event.outcome: (Success or success)
'''

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

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

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

[metadata]
creation_date = "2025/06/03"
integration = ["azure", "o365"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services.
These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access
relationships within Microsoft Entra ID (Azure AD) and Microsoft 365.
"""
false_positives = [
    """
    Legitimate administrative or security assessment activities may use these user-agents, especially in environments
    where BloodHound is employed for authorized audits. If this is expected behavior, consider adjusting the rule or
    adding exceptions for specific user-agents or IP addresses.
    """,
    """
    Expected red team assessments or penetration tests may utilize BloodHound tools to evaluate the security posture of
    Azure or Microsoft 365 environments. If this is expected behavior, consider adjusting the rule or adding exceptions
    for specific IP addresses, registered applications, JWT tokens, PRTs or user principal names (UPNs).
    """,
]
from = "now-9m"
index = ["filebeat-*", "logs-azure.*", "logs-o365.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "Entra ID Sign-in BloodHound Suite User-Agent Detected"
note = """## Triage and analysis

This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365.

The detection is based on known enumeration patterns, particularly the presence of suspicious user agent strings (e.g., `azurehound/`, `sharphound/`, `bloodhound/`) in various Azure and M365 logs. The rule monitors multiple log sources, including:

- Azure Graph API Activity Logs
- Microsoft 365 Audit Logs
- Entra ID Sign-in Logs
- Entra ID Audit Logs
- Azure Activity Logs

This ensures broader detection of credential abuse, token misuse, or unauthorized identity discovery activity from both interactive and non-interactive (API) sessions.

### Possible investigation steps

- Confirm the tool used via `user_agent.original`. Look for:
    - `azurehound/x.y.z`
    - `bloodhound/1.0`
    - `sharphound/1.0`
- Examine `url.original` or `url.path` to determine which APIs were accessed if Graph API activity logs. For example:
    - `/v1.0/organization`, `/v1.0/users`, `/v1.0/groups` may indicate user/group/tenant discovery.
- Identify the `user.id`, `user.name`, or `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine which identity executed the API request.
- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app).
- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs.
- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious?
- Review `source.ip`, `client.geo.*`, and `network.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs.
- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit.

### False positive analysis

- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization.
- Automated monitoring solutions, cloud posture scanners, or legitimate Azure/M365 integrations may generate similar traffic. Review the `app_id` and user context.
- Developer activity in test tenants may include tool usage for learning or validation purposes.

### Response and remediation

- If confirmed malicious:
    - Revoke active sessions or tokens associated with the identified user/app.
    - Disable the account or rotate credentials immediately.
    - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges.
    - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried.
    - Enable Conditional Access policies to require MFA for API and CLI-based access.
    - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads.

- If legitimate:
    - Document the source (e.g., red team operation, security tool).
    - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows.

"""
references = [
    "https://specterops.io/bloodhound-overview/",
    "https://github.com/SpecterOps/AzureHound",
    "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/",
]
risk_score = 73
rule_id = "c28750fa-4092-11f0-aca6-f661ea17fbcd"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Data Source: Graph API",
    "Data Source: Graph API Activity Logs",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where data_stream.dataset : (
    "azure.activitylogs",
    "azure.graphactivitylogs",
    "azure.auditlogs",
    "azure.signinlogs",
    "o365.audit"
) and user_agent.original regex~ "(azure|sharp|blood)(hound)/.*"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[rule.threat.technique.subtechnique]]
id = "T1069.003"
name = "Cloud Groups"
reference = "https://attack.mitre.org/techniques/T1069/003/"


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

[[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.technique]]
id = "T1201"
name = "Password Policy Discovery"
reference = "https://attack.mitre.org/techniques/T1201/"

[[rule.threat.technique]]
id = "T1526"
name = "Cloud Service Discovery"
reference = "https://attack.mitre.org/techniques/T1526/"

[[rule.threat.technique]]
id = "T1580"
name = "Cloud Infrastructure Discovery"
reference = "https://attack.mitre.org/techniques/T1580/"

[[rule.threat.technique]]
id = "T1673"
name = "Virtual Machine Discovery"
reference = "https://attack.mitre.org/techniques/T1673/"


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

[rule]
description = """
Identifies the execution of Microsoft Windows Debugging utility cdb.exe to execute shellcode or commands and from non
standard installation paths. This may indicate an attempt to evade defenses using trusted binaries.
"""
id = "57710bb9-a8d3-41ca-9b50-0f6765e9c2d7"
license = "Elastic License v2"
name = "Execution via Windows Command Line Debugging Utility"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/OtherMSBinaries/Cdb/"]
version = "1.0.4"

query = '''
process where event.action == "start" and
 (process.pe.original_file_name == "CDB.Exe" or process.name : "cdb.exe") and
  process.code_signature.subject_name == "Microsoft Corporation"  and
  process.args : ("-cf", "-c", "-pd") and
  not process.executable : ("C:\\Program Files (x86)\\*.exe", "C:\\Program Files\\*.exe") and
  not process.parent.executable : "C:\\Windows\\SysWOW64\\WerFault.exe" and
  not process.args : "!Analyze -show; dqs esp; dqs; dqs; dqs; dqs; dqs; dqs; dqs; dqs; dqs; q"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App
Engine. These firewall rules can be modified to allow or deny connections to or from virtual machine (VM) instances or
specific applications. An adversary may modify an existing firewall rule in order to weaken their target's security
controls and allow more permissive ingress or egress traffic flows for their benefit.
"""
false_positives = [
    """
    Firewall rules may be modified by system administrators. Verify that the firewall configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Firewall Rule Modification"
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 Firewall Rule Modification

In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations.

### Possible investigation steps

- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert.
- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification.
- Identify the user or service account responsible for the modification by checking the actor information in the audit logs.
- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic.
- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions.
- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change.
- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks.

### False positive analysis

- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks.
- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods.
- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts.
- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records.

### Response and remediation

- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration.
- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access.
- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected.
- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise.
- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken.
- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly.
- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/vpc/docs/firewalls",
    "https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls",
]
risk_score = 47
rule_id = "2783d84f-5091-4d7d-9319-9fceda8fa71b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule)
'''


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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects GKE API requests where a caller is impersonating a privileged cluster identity such as
system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have
broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service
account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to
secrets across namespaces and service account token minting for lateral movement.
"""
false_positives = [
    """
    Break-glass admin tooling, security scanners, or approved controllers that legitimately use impersonation against
    privileged targets may match. Map expected callers and expand client.user.email exclusions as needed.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE API Request Impersonating Privileged Identity"
note = """## Triage and analysis

### Investigating GKE API Request Impersonating Privileged Identity

Compare the real actor (`client.user.email`, `source.ip`, `user_agent.original`) with the impersonated identity in
`gcp.audit.authentication_info.authority_selector` (Cloud Audit `authenticationInfo.authoritySelector`). Confirm
whether impersonation is authorized for that principal and target identity.

### Possible investigation steps

- Review `event.action` and `gcp.audit.resource_name` for the scope of the operation performed while impersonating.
- Determine whether the real user or service account should have `impersonate` rights against the target user or group;
  inspect RBAC bindings and any recent changes.
- Correlate with adjacent audit activity (secrets, TokenRequest, RBAC writes, CSR approval) from the same source
  identity.
- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.

### False positive analysis

- Approved admin or scanner workflows that intentionally use `kubectl --as` against privileged targets may match.
  Allowlist those identities after review.

### Response and remediation

- Revoke or tighten `impersonate` permissions for unexpected identities; rotate credentials for any account that may
  have abused impersonation.
- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift.

"""
setup = """
The GCP Fleet integration with GKE audit logs enabled is required. Kubernetes impersonation (`kubectl --as`) maps to
`gcp.audit.authentication_info.authority_selector` in Fleet.
"""
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation",
    "https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/",
]
risk_score = 73
rule_id = "00c2a946-bbe8-4345-941d-9ea13da91600"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Defense Evasion",
    "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
gcp.audit.authentication_info.authority_selector:(
  "admin" or "cluster-admin" or "kubernetes-admin" or "system:admin" or "system:anonymous" or
  "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or
  "system:kube-scheduler" or "system:volume-scheduler" or
  system\:node\:* or system\:serviceaccount\:kube-system\:*
) and
not client.user.email:(
  "system:kube-controller-manager" or
  "system:kube-scheduler" or
  system\:node\:* or
  system\:serviceaccount\:kube-system\:*
)
'''

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

[[rule.threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"

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

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

[[rule.threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.authentication_info.authority_selector",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/29"

[rule]
author = ["Elastic"]
description = """
Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles
allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may
create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a
compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying
security controls, granting OAuth access, or changing mail routing.
"""
false_positives = [
    """
    Custom Google Workspace admin roles may be created by system administrators. Verify that the configuration change
    was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Custom Admin Role Created"
note = """## Triage and analysis

### Investigating Google Workspace Custom Admin Role Created

Google Workspace allows administrators to create custom admin roles with granular privileges across services such as
Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also
be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to
a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant
access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage.

This rule identifies when a custom administrative role is created in the Google Admin console.

### Possible investigation steps

- Identify the initiating (actor) account that created the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps.
- Identify the role created by reviewing `google_workspace.admin.role.name`.
- Determine whether the role creation is expected and authorized:
  - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles.
  - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign.
- Review role permissions in the Google Admin console:
  - Navigate to Account > Admin roles.
  - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details.
  - Review the Privileges tab to confirm which administrative permissions were granted.
  - Review the Admins tab to see which users or groups are currently assigned the role.
- Search Kibana for role assignments to identify principals that received the new role:
  - Search Google Workspace admin logs with a time range starting at the role creation timestamp.
  - Use the following KQL example, replacing `<ROLE_NAME>` with the value from `google_workspace.admin.role.name`:
    ```
    data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "<ROLE_NAME>"
    ```
  - Review `user.target.email` and `user.target.name` for user/group assignments.
  - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step.
- Scope for related role activity by searching for:
  - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation.
  - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes.
- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role:
  - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes.

### False positive analysis

- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process.
- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations.
- Compare the custom role’s privileges against the stated business need; overly broad privileges (for example, Super Admin–equivalent access) warrant closer review even if the creation was authorized.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds.
- For suspected compromise of the initiating admin account:
  - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence.
  - Validate recovery email/phone settings and account security posture.
- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/2406043?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
]
risk_score = 47
rule_id = "ad3f2807-2b3e-47d7-b282-f84acbbe14be"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:google_workspace.admin and event.action:CREATE_ROLE
'''

[rule.investigation_fields]
field_names = [
    "source.ip",
    "user.name",
    "user.email",
    "event.action",
    "google_workspace.admin.role.name",
]

[[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.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

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

[[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.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

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

[metadata]
creation_date = "2026/01/09"
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts
can use this to prioritize triage and response, as these hosts are more likely to be compromised.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Multiple External EDR Alerts by Host"
risk_score = 73
rule_id = "8d4d0a23-19d3-4186-a6f1-6f0760d2e070"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Domain: Endpoint"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*
| WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and
        host.id is not null and kibana.alert.risk_score > 21 and
        not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
| stats Esql.alerts_count = COUNT(*),
       Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
       Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
       Esql.process_executable_distinct_count = COUNT_DISTINCT(process.executable),
       Esql.file_path_distinct_count = COUNT_DISTINCT(file.path),
       Esql.process_command_line_distinct_count = COUNT_DISTINCT(process.command_line),
       Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score),
       Esql.process_executable_values = VALUES(process.executable),
       Esql.file_path_values = VALUES(file.path),
       Esql.user_name_values = VALUES(user.name),
       Esql.process_command_line_values = VALUES(process.command_line),
       Esql.process_parent_command_line_values = VALUES(process.parent.command_line),
       Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module
| where (
	// 3+ unique rules or processes
 (
   Esql.kibana_alert_rule_name_distinct_count >= 3 or
   (Esql.process_executable_distinct_count >= 3 and Esql.kibana_alert_rule_name_values == "External Alerts")
 ) and
 	// and 2+ rules of different severity, or 1 high/critical severity rule
 (
   Esql.kibana_alert_risk_score_distinct_count >= 2 or
   Esql.kibana_alert_risk_score_values == 73 or
   Esql.kibana_alert_risk_score_values == 99
 )
) or
 // or 5+ unique rules from the same host for 1+ path/command_line/process
 (Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.alerts_count <= 50 and
 (Esql.file_path_distinct_count >= 1 or  Esql.process_command_line_distinct_count >= 1 or Esql.process_executable_distinct_count >= 1)
)
| KEEP event.module, host.id, host.name, Esql.*
'''
note = """## Triage and analysis

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

### Investigating Multiple External EDR Alerts by Host

Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.

### Possible investigation steps

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

### False positive analysis

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

### Response and remediation

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

[metadata]
creation_date = "2020/08/29"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"

[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"

[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""


[rule]
author = ["Elastic"]
description = """
Identifies multiple consecutive logon failures from the same source address and within a short time interval.
Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt
to gain access to accounts.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Logon Failure from the same Source Address"
note = """## Triage and analysis

### Investigating Multiple Logon Failure from the same Source Address

Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/).

This rule identifies potential password guessing/brute force activity from a single address.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

#### Possible investigation steps

- Investigate the logon failure reason code and the targeted user names.
  - Prioritize the investigation if the account is critical or has administrative privileges over the domain.
- Investigate the source IP address of the failed Network Logon attempts.
  - Identify whether these attempts are coming from the internet or are internal.
- Investigate other alerts associated with the involved users and source host during the past 48 hours.
- Identify the source and the target computer and their roles in the IT environment.
- Check whether the involved credentials are used in automation or scheduled tasks.
- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
- Examine the source host for derived artifacts that indicate compromise:
  - Observe and collect information about the following activities in the alert source host:
    - Attempts to contact external domains and addresses.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity

### False positive analysis

- Understand the context of the authentications by contacting the asset owners. This activity can be related to a new or existing automation or business process that is in a failing state.
- Authentication misconfiguration or obsolete credentials.
- Service account password expired.
- Domain trust relationship issues.
- Infrastructure or availability issues.

### Related rules

- Multiple Logon Failure Followed by Logon Success - 4e85dc8a-3e41-40d8-bc28-91af7ac6cf60

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the source host to prevent further post-compromise behavior.
- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625",
    "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624",
    "https://social.technet.microsoft.com/Forums/ie/en-US/c82ac4f3-a235-472c-9fd3-53aa646cfcfd/network-information-missing-in-event-id-4624?forum=winserversecurity",
    "https://serverfault.com/questions/379092/remote-desktop-failed-logon-event-4625-not-logging-ip-address-on-2008-terminal-s/403638#403638",
]
risk_score = 47
rule_id = "48b6edfc-079d-4907-b43c-baffa243270d"
setup = """## Setup

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index
| where event.category == "authentication" and host.os.type == "windows" and event.action == "logon-failed" and
  winlog.logon.type == "Network" and source.ip is not null and winlog.computer_name is not null and
  not cidr_match(TO_IP(source.ip), "127.0.0.0/8", "::1") and
  not user.name in ("ANONYMOUS LOGON", "-") and not user.name like "*$" and user.domain != "NT AUTHORITY" and
  /*
    noisy failure status codes often associated to authentication misconfiguration
     0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine.
     0XC000005E - There are currently no logon servers available to service the logon request.
     0XC0000133 - Clocks between DC and other computer too far out of sync.
     0XC0000192 An attempt was made to logon, but the Netlogon service was not started.
     0xc00000dc - DC is in shutdown phase, it will normally tell current clients to use another DC for authentication.
  */
  not winlog.event_data.Status in ("0xc000015b", "0xc000005e", "0xc0000133", "0xc0000192", "0xc00000dc")
// truncate the timestamp to a 60-second window
| eval Esql.time_window = date_trunc(60 seconds, @timestamp)
| stats Esql.failed_auth_count = COUNT(*),
        Esql.count_distinct_target_user_name = count_distinct(winlog.event_data.TargetUserName),
        Esql.target_user_name_values = VALUES(winlog.event_data.TargetUserName),
        Esql.user_domain_values = VALUES(user.domain),
        Esql.error_codes = VALUES(winlog.event_data.Status),
        Esql.data_stream_namespace.values = VALUES(data_stream.namespace) by winlog.computer_name, source.ip, Esql.time_window, winlog.logon.type
| where Esql.failed_auth_count >= 100 and Esql.count_distinct_target_user_name >= 2
| eval user.name = MV_FIRST(Esql.target_user_name_values)
| KEEP winlog.computer_name, source.ip, user.name, Esql.time_window, winlog.logon.type, Esql.*
'''


[[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.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

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