Elastic rules: 0e

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

[rule]
author = ["Elastic"]
description = """
Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a
group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin
privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or
privilege escalation.
"""
false_positives = [
    """
    Legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event.
    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. User
    additions from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it
    can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM User Addition to Group"
note = """## Triage and analysis

### Investigating AWS IAM User Addition to Group

This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).

#### Possible investigation steps

- **Identify the actor and target**  
  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.

- **Examine the group’s privileges**  
  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.

- **Correlate with surrounding activity**  
  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).


### False positive analysis

- Onboarding or role transitions may legitimately add users to groups.  
- Automated Identity-Management pipelines may add many users to service groups; validate know

### Response and remediation

- **Containment**:
  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
  - Temporarily restrict group policy changes while assessing blast radius.

- **Investigation and scoping**:
  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
  - Confirm whether other users were added to the same group within the same window. 

- **Recovery and hardening**: 
  - Enforce least privilege by redesigning large-group membership. 
  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.

### Additional information
[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
"""
references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html"]
risk_score = 21
rule_id = "333de828-8190-4cf5-8d7c-7575846f6fe0"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

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

[metadata]
creation_date = "2026/05/27"
integration = ["aws"]
maturity = "production"
updated_date = "2026/05/27"

[rule]
author = ["Elastic"]
description = """
Detects successful S3 GetObject calls targeting high-value credential and secret files commonly
stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys
("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files,
and other private key patterns. These file types are high-yield targets for credential harvesting
from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore,
and other AWS-internal data movement that legitimately reads these files.
"""
false_positives = [
    """
    Legitimate CI/CD pipelines, infrastructure tooling, or configuration management systems may retrieve
    secret files from S3 as part of their normal operation. Validate the calling identity, user agent,
    and source IP against known automation accounts and expected access patterns.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS S3 Credential File Retrieved from Bucket"
note = """## Triage and analysis

### Investigating AWS S3 Credential File Retrieved from Bucket

S3 is frequently used to store configuration files, scripts, and secrets. When files with credential-like
names are accessed, it warrants investigation to ensure that the retrieval was authorized.

### Possible investigation steps

- **Identify the accessed file**: Review `aws.cloudtrail.request_parameters` for the bucket name and key.
  Determine whether the bucket is intended to store secrets.
- **Verify the caller**: Inspect `aws.cloudtrail.user_identity.arn` and `source.ip`. If the caller is not
  an approved automation role, escalate immediately.
- **Check bucket permissions**: Determine if the bucket is publicly accessible or if the key naming
  pattern was intentionally exposed.
- **Look for downstream actions**: Search for subsequent IAM, STS, or console actions from the same
  identity shortly after the object retrieval, which may indicate successful credential use.

### False positive analysis

- Legitimate backup or restore processes may access credential files stored in S3 as part of their
  workflow. Validate the calling identity and user agent against known automation accounts.
- CI/CD pipelines that retrieve secrets from S3 during deployment may trigger this rule. Verify the
  source IP and ARN match expected automation infrastructure.

### Response and remediation

- Immediately disable the access key identified in `aws.cloudtrail.user_identity.access_key_id` if
  the retrieval is determined to be unauthorized.
- Audit the S3 bucket for overly permissive policies or public access configurations.
- Rotate any credentials stored in the accessed object — treat them as compromised.
- Review all CloudTrail events from the same identity in the preceding 30 minutes for signs of
  lateral movement, IAM changes, or resource creation.
- Implement S3 bucket policies or IAM conditions restricting access to credential files to only
  authorized identities and source IPs.
"""
references = [
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html",
]
risk_score = 47
rule_id = "2f0ee9fe-4529-4b9e-9f78-6c81ef33c6ba"
severity = "medium"
setup = """S3 data event logging is required for this rule. This rule detects S3 GetObject events,
which are data plane events not logged by default. To enable: CloudTrail console → Trails →
[trail name] → Data events → Add S3 → select the buckets to monitor (or all buckets with a wildcard).
Without this configuration, the rule produces no alerts.

Refer to the AWS documentation on
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html[logging data events]
for detailed steps.
"""
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS S3",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "s3.amazonaws.com" and
    event.action: "GetObject" and
    event.outcome: "success" and
    aws.cloudtrail.flattened.request_parameters.key: (
        */.aws/credentials or
        */.aws/config or
        */id_rsa or
        */id_ed25519 or
        */id_ecdsa or
        */id_dsa or
        */.env or
        */.env.* or
        *.ppk or
        *.pem or
        *.key or
        *private_key* or
        */.ssh/authorized_keys
    ) and
    not aws.cloudtrail.user_identity.type: "AWSService"
'''

[[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.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/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 = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

[rule.alert_suppression]
group_by = ["source.ip", "cloud.account.id"]
duration = {value = 5, unit = "m"}
missing_fields_strategy = "suppress"

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

[metadata]
creation_date = "2024/03/24"
integration = ["endpoint"]
maturity = "production"
promotion = true
updated_date = "2025/07/02"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule
allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend
behavior preventions only, and does not include detection only alerts.
"""
enabled = false
from = "now-2m"
index = ["logs-endpoint.alerts-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Behavior - Prevented - Elastic Defend"
note = """## Triage and analysis

### Investigating Behavior - Prevented - Elastic Defend

Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity.

### Possible investigation steps

- Assess whether this activity is prevalent in your environment by looking for similar occurrences across hosts.
- Verify the detailed activity of the process that triggered the alert (process tree, child process, process arguments, network, files, libraries and registry events).
- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user).
- Particular attention should be paid to instances where the same process is triggering multiple alerts (more than 2 or 3) within a short period of time.
- Even the the process is signed by a valid certificate, verify the if it's running from the expected location or if it's loading any suspicious libraries or any sign of code injection.


### False positive analysis

- Same alert observed on a high number of hosts with similar details.
- High count of the same alert on a specific host over a long period of time.

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
   - Contain the affected system by isolating it from the network to prevent further spread of the attack.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- 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://github.com/elastic/protections-artifacts/tree/main/behavior",
    "https://docs.elastic.co/en/integrations/endpoint",
]
risk_score = 21
rule_id = "eb804972-ea34-11ee-a417-f661ea17fbce"
rule_name_override = "message"
setup = """## Setup

### Elastic Defend Alerts
This rule is designed to capture specific alerts generated by Elastic Defend.

To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules:

Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce)
Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce)
Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce)
Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce)
Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce)
Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce)
Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce)
Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce)

To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306).

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "low"
tags = ["Data Source: Elastic Defend", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind : alert and event.code : behavior and event.type : denied and event.outcome : success
'''


[[rule.exceptions_list]]
id = "endpoint_list"
list_id = "endpoint_list"
namespace_type = "agnostic"
type = "endpoint"

[[rule.risk_score_mapping]]
field = "event.risk_score"
operator = "equals"
value = ""

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "low"
value = "21"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "medium"
value = "47"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "high"
value = "73"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "critical"
value = "99"

[metadata]
creation_date = "2026/05/23"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/05/23"

[rule]
author = ["Elastic"]
description = """
Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token
paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read
IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP
decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present.
"""
false_positives = [
    """
    Cloud agents (SSM, waagent, cloud-init, instance connect) and authorized scanners may reach the same paths during
    provisioning or health checks. Exclude known agent user agents, source hosts, or parent processes after baselining.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.http*", "packetbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Cloud Instance Metadata Credential Path HTTP Request"
note = """## Triage and analysis

### Investigating Cloud Instance Metadata Credential Path HTTP Request

This rule matches outbound HTTP GETs to `169.254.169.254` where the URL path requests IAM credentials or cloud OAuth
tokens, filtered to common scripting runtimes, suspicious executable paths, or tool-like user agents.

### Investigation steps

- Confirm `url.path` (AWS `security-credentials`, GCP `oauth2/access_token`, Azure `metadata/identity/oauth2/token`).
- Review `process.name`, `process.executable`, and `user_agent.original` — scripted tools and temp-path binaries are higher risk.
- Check `host.name` or `host.hostname` and whether the workload should run on a cloud VM with an instance profile or managed identity.
- Correlate with cloud audit or sign-in logs for role assumption or token use shortly after the request.
- If credentials may have been exposed, rotate the instance role or managed identity and review API activity from that principal.

### False positives

- Platform agents and bootstrap scripts on new instances; allowlist by user agent or host group where validated.

### Response

- Restrict IMDS access (IMDSv2 hop limit, network policy) and remove unnecessary instance permissions.
- Investigate the host for follow-on credential use or lateral movement.

## Setup

Deploy the [Network Packet Capture](https://www.elastic.co/docs/reference/integrations/network_traffic) integration via Fleet on cloud workloads.

- Enable **Capture HTTP Traffic** and include ports **80** and **443**.
- Enable **Monitor Processes** so network events include the process that initiated the connection.
- Prefer ECS field remapping (`map_to_ecs`) on integration data streams.
"""
references = [
    "https://www.elastic.co/docs/reference/integrations/network_traffic",
    "https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/"
]
risk_score = 47
rule_id = "73dd1f2c-3c24-4e13-a64b-dfd510e9fd98"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Network",
    "OS: Linux",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where event.module == "network_traffic" and destination.ip == "169.254.169.254" and destination.port == 80 and
http.request.method == "GET" and url.path : (
  "/latest/meta-data/iam/security-credentials/*",
  "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*",
  "*metadata/identity/oauth2/token*"
) and (
  ?process.name : (
    "curl", "wget", "python*", "node", "bun", "php*", "ruby", "perl", "bash", "dash", "sh", "tcsh", "tclsh", "wish",
    "csh", "zsh", "ksh", "fish", "mksh", "busybox",
    "bun.exe", "node.exe", "powershell.exe", "cmd.exe", "curl.exe", "wget.exe", "rundll32.exe", "w3wp.exe", "java*", 
    "go", "nc", "netcat", "nginx", "apache*", "httpd", "tomcat*", "catalina", "spring*", "dotnet", "gunicorn", "uwsgi", 
    ".*", "osascript"
  ) or ?process.executable : (
    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", "?:\\ProgramData\\*"
  ) or user_agent.original : (
    "curl*", "wget*", "python*", "ruby*", "Go-http-client*", "node*", "axios*", "undici*", "java*", "php*", "Bun*",
    "Apache-HttpClient*", "okhttp*", "RestTemplate*", "*WindowsPowerShell*", "*roadtools*", "*fasthttp*", "*azurehound*", "*bloodhound*", "*aiohttp*"
  )
)
'''


[[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]
description = """
Detects LDAP search queries commonly used to enumerate domain password policies. Adversaries may perform this activity
to identify potential weaknesses that could be exploited for privilege escalation or lateral movement.
"""
id = "bbf68a5c-9346-40f4-8a9b-da3d9136f39f"
license = "Elastic License v2"
name = "Domain Password Policy Enumeration via LDAP"
os_list = ["windows"]
reference = ["https://attack.mitre.org/techniques/T1201/"]
version = "1.0.3"

query = '''
api where process.Ext.api.name == "ldap_search" and user.id != "S-1-5-18" and
not process.executable :
             ("?:\\Program Files\\Azure Advanced Threat Protection Sensor\\*\\Microsoft.Tri.Sensor.exe",
              "?:\\Windows\\ADFS\\Microsoft.IdentityServer.ServiceHost.exe",
              "?:\\Windows\\ADWS\\Microsoft.ActiveDirectory.WebServices.exe") and
(
  (process.Ext.api.parameters.search_filter : "*msDS-PasswordSettings*" and
   process.Ext.api.parameters.attribute_list == "msDS-MinimumPasswordLength" and process.Ext.api.parameters.attribute_list == "msDS-LockoutThreshold") or

  process.Ext.api.parameters.search_filter : "*(pwdlastset>=*(operatingSystem=*windows*))"
)
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"
[[threat.technique.subtechnique]]
id = "T1087.002"
name = "Domain Account"
reference = "https://attack.mitre.org/techniques/T1087/002/"


[[threat.technique]]
id = "T1201"
name = "Password Policy Discovery"
reference = "https://attack.mitre.org/techniques/T1201/"


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

[internal]
min_endpoint_version = "9.1.0"

[metadata]
creation_date = "2024/12/11"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password
(TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short
time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP
codes by generating several sessions and attempt to guess the correct code.
"""
false_positives = [
    """
    Based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed
    TOTP code attempts in a short time-span over multiple sessions.
    """,
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID MFA TOTP Brute Force Attempted"
note = """## Triage and analysis

### Investigating Entra ID MFA TOTP Brute Force Attempted

This rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code.

#### Possible Investigation Steps:

    - Check the source addresses associated with the failed TOTP attempts.
    - Determine if the source IP address is consistent with the user’s typical login locations.
    - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user’s normal activity).
    - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues.
    - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes.
    - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt.
    - Review conditional access policies applied to the user or group as reported by the sign-in logs.
    - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script.
        - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate.
    - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services.
    - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate.

#### False Positive Analysis:

    - Verify if the failed attempts could result from the user’s unfamiliarity with TOTP codes or issues with device synchronization.
    - Check if the user recently switched MFA methods or devices, which could explain multiple failures.
    - Determine if this is whitebox testing or a developer testing MFA integration.

#### Response and Remediation:

    - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts.
    - Notify the user of suspicious activity and validate their access to the account.
    - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user.
    - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior.
    - Consider a different MFA method or additional security controls to prevent future bypass attempts.
    - Implement additional monitoring to track high-frequency authentication failures across the environment.
    - Audit historical logs for similar patterns involving other accounts to identify broader threats.
    - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity.
"""
references = [
    "https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass",
    "https://learn.microsoft.com/en-us/entra/identity/",
    "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
]
risk_score = 47
rule_id = "3fac01b2-b811-11ef-b25b-f661ea17fbce"
setup = """#### Required Entra ID Sign-In Logs
This rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration.
"""
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",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.signinlogs-* metadata _id, _version, _index

| where
    // filter for Entra Sign-in Logs
    data_stream.dataset == "azure.signinlogs"
    and azure.signinlogs.operation_name == "Sign-in activity"
    and azure.signinlogs.properties.user_type == "Member"

    // filter for MFA attempts with OATH conditional access attempts or TOTP
    and azure.signinlogs.properties.mfa_detail.auth_method == "OATH verification code"

    // filter on failures only from brute-force attempts
    and (
            (
                azure.signinlogs.result_signature == "FAILURE" and
                azure.signinlogs.result_description == "Authentication failed during strong authentication request."
            ) or azure.signinlogs.properties.status.error_code == 500121
        )

| stats
    Esql.event_count = count(*),
    Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id),
    Esql.source_address_values = values(source.address),
    Esql.azure_tenant_id_valuues = values(azure.tenant_id),
    Esql_priv.azure_identity_values = values(azure.signinlogs.identity),
    Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),
    Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),
    Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),
    Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),
    Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol),
    Esql.azure_signinlogs_properties_client_app_used_values = values(azure.signinlogs.properties.client_app_used),
    Esql.azure_signinlogs_properties_client_credential_type_values = values(azure.signinlogs.properties.client_credential_type),
    Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),
    Esql.azure_signinlogs_properties_correlation_id_values = values(azure.signinlogs.properties.correlation_id),
    Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive),
    Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = values(azure.signinlogs.properties.mfa_detail.auth_method),
    Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),
    Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),
    Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),
    Esql.azure_signinlogs_properties_risk_detail_values = values(azure.signinlogs.properties.risk_detail),
    Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),
    Esql.azure_signinlogs_properties_original_request_id_values = values(azure.signinlogs.properties.original_request_id),
    Esql.user_id_values = values(user.id)
    by user.id

| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties_session_id_count_distinct >= 10

| keep
    Esql.event_count,
    Esql.azure_signinlogs_properties_session_id_count_distinct,
    Esql.source_address_values,
    Esql.azure_tenant_id_valuues,
    Esql_priv.azure_identity_values,
    Esql_priv.azure_signinlogs_properties_user_principal_name_values,
    Esql.azure_signinlogs_properties_app_id_values,
    Esql.azure_signinlogs_properties_app_display_name_values,
    Esql.azure_signinlogs_properties_authentication_requirement_values,
    Esql.azure_signinlogs_properties_authentication_protocol_values,
    Esql.azure_signinlogs_properties_client_app_used_values,
    Esql.azure_signinlogs_properties_client_credential_type_values,
    Esql.azure_signinlogs_properties_conditional_access_status_values,
    Esql.azure_signinlogs_properties_correlation_id_values,
    Esql.azure_signinlogs_properties_is_interactive_values,
    Esql.azure_signinlogs_properties_mfa_detail_auth_method_values,
    Esql.azure_signinlogs_properties_resource_display_name_values,
    Esql.azure_signinlogs_properties_resource_id_values,
    Esql.azure_signinlogs_properties_risk_state_values,
    Esql.azure_signinlogs_properties_risk_detail_values,
    Esql.azure_signinlogs_properties_status_error_code_values,
    Esql.azure_signinlogs_properties_original_request_id_values,
    Esql.user_id_values
'''


[[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.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[metadata]
creation_date = "2025/03/10"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/12"

[rule]
author = ["Elastic"]
description = """
Identifies rare instances of authentication methods for Microsoft Entra ID principal users. An adversary with stolen
credentials may attempt to authenticate with an unusual method, which may indicate an attempt to bypass conditional
access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication method may not be commonly
used by the user based on their historical sign-in activity.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Sign-in with Unusual Authentication Type"
note = """## Triage and analysis

### Investigating Entra ID User Sign-in with Unusual Authentication Type

Identifies rare instances of authentication methods for Microsoft Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with an unusual method, which may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication method may not be commonly used by the user based on their historical sign-in activity.

**This is a New Terms rule that focuses on the first occurrence of an Entra ID principal user `azure.signinlogs.properties.user_principal_name` and their authentication method `azure.signinlogs.properties.authentication_details.authentication_method` in the last 14 days.**

### Possible investigation steps

- Identify the source IP address by reviewing `source.ip`. Determine whether it is associated with known malicious activity, an unexpected location or hosting provider, or approved corporate infrastructure.
- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is privileged or otherwise high value, and compare the sign-in with the user's recent activity.
- Examine `azure.signinlogs.properties.authentication_details.authentication_method` and determine whether the method is expected for the user. Review recent authentication-method registration or modification events.
- Review `azure.signinlogs.properties.app_id`, `azure.signinlogs.properties.client_app_used`, and the target resource to determine whether the application and access pattern are expected.
- Examine device, browser, user-agent, authentication protocol, and token details for signs of an unfamiliar client or session.
- Review `azure.signinlogs.properties.authentication_requirement` and the applicable conditional access policies to determine why the sign-in did not require MFA.

## False positive analysis

### Common benign scenarios
- Users enrolling in or switching to a different authentication method may trigger this detection the first time the method is observed.
- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`.
- Changes to an organization's authentication or conditional access policies may cause a previously unseen authentication method to be recorded for a user.

### How to reduce false positives
- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`.
- Exclude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication.
- Correlate alerts with approved authentication-method enrollment or policy changes before adding exceptions.

## Response and remediation

### Immediate actions
- Block the source IP address in `source.ip` if determined to be malicious.
- If the sign-in is unauthorized, disable the affected account, revoke active sessions and tokens, and reset its credentials.
- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`.
- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks.
- Review conditional access policies to enforce risk-based authentication and block unauthorized access recorded in `azure.signinlogs.properties.authentication_requirement`.

### Long-term mitigation
- Implement a zero-trust security model by enforcing least privilege access and continuous authentication.
- Regularly review and update conditional access policies to ensure they are effective against evolving threats.
- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`.
- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks.
- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft.
"""
risk_score = 47
rule_id = "9e11faee-fddb-11ef-8257-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Platform: Entra ID",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and event.category: "authentication"
    and azure.signinlogs.properties.user_type: "Member"
    and not azure.signinlogs.properties.device_detail.browser: *
    and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK"
    and not azure.signinlogs.properties.authentication_requirement: "multiFactorAuthentication"
    and azure.signinlogs.properties.authentication_details.authentication_method:*
    and event.outcome:success
'''


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



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

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



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

[rule.new_terms]
field = "new_terms_fields"
value = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.authentication_details.authentication_method",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"

[rule]
description = """
Identifies the execution of a Windows script with a file name following a phishing naming convention commonly used by
SocGolish. SocGholish is an initial access threat that leverages drive-by-downloads masquerading as software updates.
"""
id = "28d4818c-7da1-4173-bb7c-4b7bb8f0976f"
license = "Elastic License v2"
name = "Execution via Suspicious JavaScript Updates"
os_list = ["windows"]
reference = ["https://malpedia.caad.fkie.fraunhofer.de/details/js.fakeupdates"]
version = "1.0.27"

query = '''
process where event.action == "start" and
 process.pe.original_file_name in ("cscript.exe", "wscript.exe") and
 (
  process.args :
        (
         /* Temp archive file */
         "?:\\Users\\*\\AppData\\Local\\Temp\\7z*\\*.Update.*.js",
         "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*.Update.*.js",
         "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*\\*.Update.*.js",
         "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*",

         /* extracted by victim user to a random folder */
         "?:\\Users\\*\\chrome.update.*.js",
         "?:\\Users\\*\\firefox.update.*.js",
         "?:\\Users\\*\\Opera.update.*.js",
         "?:\\Users\\*\\Firefox.js",
         "?:\\Users\\*\\Chrome.js",
         "?:\\Users\\*\\Edge.js",
         "?:\\Users\\*\\Opera.js"
         ) or

  /* execution from mounted ISO or IMG  */
   (process.args regex~ """[D-Z]:\\[a-z0-9]+\.Update\.[a-z0-9]+\.js""" and process.working_directory : "?:\\" )
  )
'''

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 = "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.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.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



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


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

[rule]
author = ["Elastic"]
description = """
Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are
user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will
not be updated automatically and could lead to privilege creep if not carefully scrutinized.
"""
false_positives = [
    """
    Custom role creations 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 creations 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 Custom Role Creation"
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 Custom Role Creation

Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations.

### Possible investigation steps

- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role.
- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations.
- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions.
- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies.
- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs.

### False positive analysis

- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior.
- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern.
- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly.
- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities.

### Response and remediation

- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization.
- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege.
- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation.
- Implement additional monitoring on the identified user or service account to detect any further suspicious activities.
- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles.
- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions.

## 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-custom-roles"]
risk_score = 73
rule_id = "aa8007f0-d1df-49ef-8520-407857594827"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

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

[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 = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[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 = "2020/09/22"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when a new service account is created in Google Cloud Platform (GCP). A service account is a special type of
account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
through domain-wide delegation. If service accounts are not tracked and managed properly, they can present a security
risk. An adversary may create a new service account to use during their operations in order to avoid using a standard
user account and attempt to evade detection.
"""
false_positives = [
    """
    Service accounts can be created by system administrators. Verify that the behavior 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 Service Account Creation"
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 Service Account Creation

In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation.

### Possible investigation steps

- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation.
- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities.
- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose.
- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies.
- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account.

### False positive analysis

- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities.
- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts.
- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities.
- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts.

### Response and remediation

- Immediately disable the newly created service account to prevent any unauthorized access or actions.
- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted.
- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions.
- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination.
- Implement additional monitoring and alerting for service account creations to detect similar activities in the future.
- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources.
- Document the incident and response actions taken to improve future detection and response capabilities.

## 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/service-accounts"]
risk_score = 21
rule_id = "7ceb2216-47dd-4e64-9433-cddc99727623"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

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

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

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

[metadata]
creation_date = "2025/12/04"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
Detects when GenAI processes perform encoding or chunking (base64, gzip, tar, zip) followed by outbound network
activity. This sequence indicates data preparation for exfiltration. Attackers encode or compress sensitive data before
transmission to obfuscate contents and evade detection. Legitimate GenAI workflows rarely encode data before network
communications.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "GenAI Process Performing Encoding/Chunking Prior to Network Activity"
note = """## Triage and analysis

### Investigating GenAI Process Performing Encoding/Chunking Prior to Network Activity

GenAI processes performing encoding or chunking operations followed by network activity is highly suspicious. This behavior indicates data preparation for exfiltration via GenAI prompts or agents, which is a strong indicator of malicious activity.

### Possible investigation steps

- Review the GenAI process that performed the encoding to identify which tool is running and verify if it's an expected/authorized tool.
- Examine the encoding/chunking command line arguments to understand what data is being processed.
- Review the network connection details to identify the destination and determine if it's expected.
- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user.
- Review the data that was encoded to determine if it contains sensitive information.
- Determine whether the encoding was initiated by a GenAI agent or automation loop rather than a user action.
- Check whether the encoded data size or entropy suggests credential files, browser data, SSH keys, or cloud tokens.
- Validate that the GenAI tool is installed from a trusted source and has not been modified.

### False positive analysis

- Legitimate data processing workflows that use GenAI tools may trigger this rule if they encode data before transmission.
- Some local developer workflows may encode files before uploading training data or embeddings; confirm whether the host is a model-development workstation.

### Response and remediation

- Terminate the GenAI process and any spawned encoding/network processes to stop the malicious activity.
- Review and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool.
- Investigate the encoded data and network destination to determine the scope of potential data exfiltration.
"""
references = [
    "https://atlas.mitre.org/techniques/AML.T0086",
    "https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 47
rule_id = "c3d4e5f6-a7b8-9012-cdef-123456789abc"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: macOS",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
    "Domain: LLM",
    "Mitre Atlas: T0086",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by process.entity_id with maxspan=30s

  // Encoding/compression followed by network activity
  [process where event.type == "start"
     and event.type == "start"

     // Encoding/chunking tools
     and (
       // Native encoding tools
       process.name in ("base64", "gzip", "tar", "zip", "split", "7z", "7za", "7zr") or
       
       // PowerShell encoding
       (process.name in ("powershell.exe", "pwsh.exe") and
        process.command_line like~ ("*Compress-Archive*", "*[Convert]::ToBase64String*")) or
       
       // Python encoding
       (process.name like~ "python*" and
        process.command_line like~ ("*base64*", "*gzip*", "*zlib*", "*tarfile*", "*zipfile*")) or
       
       // Node.js encoding
       (process.name in ("node.exe", "node") and
        process.command_line like~ ("*Buffer.from*", "*zlib*", "*gzip*") and
        not process.command_line like~ ("*mcp*start*", "*mcp-server*", "*npm exec*mcp*"))
     )

     // GenAI parent process
     and (
       process.parent.name in (
         "ollama.exe", "ollama", "Ollama",
         "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe",
         "lmstudio.exe", "lmstudio", "LM Studio",
         "claude.exe", "claude", "Claude",
         "cursor.exe", "cursor", "Cursor", "Cursor Helper", "Cursor Helper (Plugin)",
         "copilot.exe", "copilot", "Copilot",
         "codex.exe", "codex",
         "Jan", "jan.exe", "jan", "Jan Helper",
         "gpt4all.exe", "gpt4all", "GPT4All",
         "gemini-cli.exe", "gemini-cli",
         "genaiscript.exe", "genaiscript",
         "grok.exe", "grok",
         "qwen.exe", "qwen",
         "koboldcpp.exe", "koboldcpp", "KoboldCpp",
         "llama-server", "llama-cli"
       ) or
       
       // Node/Deno with GenAI frameworks
       (process.parent.name in ("node.exe", "node", "deno.exe", "deno") and
        process.parent.command_line like~ (
          "*ollama*", "*mcp-server*", "*@modelcontextprotocol*", "*langchain*", "*autogpt*",
          "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*",
          "*haystack*", "*openai*", "*anthropic*", "*cohere*", "*mistral*"
        )) or
       
       // Python with GenAI frameworks
       (process.parent.name like~ "python*" and
        process.parent.command_line like~ (
          "*ollama*", "*mcp-server*", "*langchain*", "*autogpt*", "*babyagi*",
          "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*",
          "*openai*", "*anthropic*", "*cohere*", "*mistral*"
        ))
     )
  ] by process.entity_id

  // Outbound network connection (non-local)
  [network where event.type == "start"
     and event.action == "connection_attempted"
     and destination.ip != null
     and not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
                       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
                       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
                       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
                       "FF00::/8")
     
  ] by process.entity_id
'''


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

[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

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

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

[[rule.threat.technique]]
id = "T1560"
name = "Archive Collected Data"
reference = "https://attack.mitre.org/techniques/T1560/"

[[rule.threat.technique.subtechnique]]
id = "T1560.001"
name = "Archive via Utility"
reference = "https://attack.mitre.org/techniques/T1560/001/"

[[rule.threat.technique.subtechnique]]
id = "T1560.002"
name = "Archive via Library"
reference = "https://attack.mitre.org/techniques/T1560/002/"

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

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

[[rule.threat.technique]]
id = "T1030"
name = "Data Transfer Size Limits"
reference = "https://attack.mitre.org/techniques/T1030/"

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

[metadata]
creation_date = "2020/08/11"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/07/19"

[rule]
author = ["Elastic"]
description = """
Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are
accepting inbound network connections over the default Elasticsearch port.
"""
false_positives = [
    """
    If you have front-facing proxies that provide authentication and TLS, this rule would need to be tuned to eliminate
    the source IP address of your reverse-proxy.
    """,
]
from = "now-9m"
index = ["packetbeat-*", "logs-network_traffic.*"]
language = "kuery"
license = "Elastic License v2"
name = "Inbound Connection to an Unsecure Elasticsearch Node"
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 Inbound Connection to an Unsecure Elasticsearch Node

Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.

### Possible investigation steps

- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources.
- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity.
- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs.
- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls.
- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access.
- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents.

### False positive analysis

- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise.
- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments.
- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule.
- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration.
- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers.
- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only.
- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat.
- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats.
- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts.

## Setup

This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation."""
references = [
    "https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html",
    "https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers",
]
risk_score = 47
rule_id = "31295df3-277b-4c56-a1fb-84e31b4222a9"
severity = "medium"
tags = [
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Reconnaissance",
    "Domain: Endpoint",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
(data_stream.dataset: network_traffic.http or (event.category: network_traffic and network.protocol: http)) and
http.response.status_code: 200 and destination.port: 9200 and network.direction: (inbound or ingress) and
not http.response.headers.content-type: "image/x-icon" and not http.request.headers.authorization: *
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


[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 = "T1595"
name = "Active Scanning"
reference = "https://attack.mitre.org/techniques/T1595/"


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

[metadata]
creation_date = "2024/03/24"
integration = ["endpoint"]
maturity = "production"
promotion = true
updated_date = "2025/07/02"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows
you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend
malicious file detections only, and does not include prevention alerts.
"""
enabled = false
from = "now-2m"
index = ["logs-endpoint.alerts-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Malicious File - Detected - Elastic Defend"
note = """## Triage and analysis

### Investigating Malicious File - Detected - Elastic Defend

Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with  hand-written rules by our threat researchers.

Files are scanned on write or deletion, process executables are scanned on executions and libraries are scanned on load. You can differentiate these types by looking at the `event.action` field in the alert. It can be execution, `load`, `creation`, `modification`, or `deletion`. Scanning files written to disk is best effort, while execution or load scanning is done ‘in-line’ for true prevention.

### Possible investigation steps

- For machine learning (ML) malware alerts the `file.Ext.malware_classification.score` and `file.Ext.malware_classification.version` fields indicate which model version was used to classify the file and the classification score (0 to 1).
- For malware signature hits, `threat_name` is an important field which will guide the user on what malware family the sample belongs to.
- For Yara matches, Malware alerts do provide the specific binary content identified by the yara rule in the alert metadata (it is base64 encoded and stored in the `matches` field).
- A file can also hit on multiple Yara signatures. In the alert metadata, the `primary` signature (`malware_signature.primary`) will be whichever we determine to have the highest severity.
- Malicious file alerts for files in download directories or written by browsers, office applications, script interpreters or other lolbins are especially correlated with malicious activity.
- Particular attention should be paid to files located in suspicious directories like `Public` folder, `Downloads`, `Temp` and `ProgramData`.
- Verify if the file is signed or not using the `file.Ext.code_signature` field. Even if the file is signed with a valid certificate verify the global prevalance of that signed in your environment.
- Verify the malicious file timestamp metadata using `file.created`, `file.mtime` and `file.accessed` to asses exactly if it's an old or new infection.
- Investigate the activity of the process that created, modified or loaded the malicious file (parent process tree, process.command_line, child processes, network, registry and files events).
- Assess whether this file is prevalent in the environment by looking for similar occurrences across hosts by `file.hash.sha256` or by `file.name` patterns.
- Verify the activity of the `user.name` associated with Malware alert (local or remote actity, privileged or standard user).
- Verify if there are any other Alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time.
### False positive analysis

- Other endpoint security vendors especially with their quarantine folders.
- Dynamically generated or compiled executables such as from csc.exe or other compilers. Due to the dynamic nature, each instance will likely have a unique hash and no signer

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
   - Contain the affected system by isolating it from the network to prevent further spread of the attack.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- 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://github.com/elastic/protections-artifacts/tree/main/yara",
    "https://docs.elastic.co/en/integrations/endpoint",
]
risk_score = 47
rule_id = "f2c3caa6-ea34-11ee-a417-f661ea17fbce"
rule_name_override = "message"
setup = """## Setup

### Elastic Defend Alerts
This rule is designed to capture specific alerts generated by Elastic Defend.

To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules:

Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce)
Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce)
Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce)
Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce)
Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce)
Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce)
Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce)
Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce)

To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306).

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = ["Data Source: Elastic Defend", "Tactic: Execution", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind : alert and event.code : malicious_file and (event.type : allowed or (event.type: denied and event.outcome: failure))
'''


[[rule.exceptions_list]]
id = "endpoint_list"
list_id = "endpoint_list"
namespace_type = "agnostic"
type = "endpoint"

[[rule.risk_score_mapping]]
field = "event.risk_score"
operator = "equals"
value = ""

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "low"
value = "21"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "medium"
value = "47"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "high"
value = "73"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "critical"
value = "99"

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



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

[metadata]
creation_date = "2023/08/28"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent network
connection event. This behavior can indicate the set up of a reverse tcp connection to a command-and-control server.
Attackers may spawn reverse shells to establish persistence onto a target system.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connection via Recently Compiled Executable"
risk_score = 47
rule_id = "64cfca9e-0f6f-4048-8251-9ec56a055e9e"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id with maxspan=1m
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.name like~ (
     "gcc*", "g++*", "c++", "cc", "c99", "c89", "cc1*", "cc1plus*", "clang*", "clang++*",
     "musl-gcc", "musl-clang", "*-linux-gnu-gcc*", "*-linux-gnu-g++*", "*-pc-linux-gnu-gcc*",
     "tcc", "zig", "ccache", "distcc"
   )] by process.args
  [file where host.os.type == "linux" and event.action == "creation" and process.name like~ (
    "ld", "ld.*", "lld", "ld.lld", "mold", "collect2", "*-linux-gnu-ld*", "*-pc-linux-gnu-ld*"
   )] by file.name
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec"] by process.name
  [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.ip != null and not (
     cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1") or
     process.name in (
       "simpleX", "conftest", "ssh", "python", "ispnull", "pvtui", "npreal2d", "ruby", "source", "ssh", "git-remote-http",
       "sshd-session", "gendb", "sqlplus"
     )
   )] by process.name
'''
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 Network Connection via Recently Compiled Executable

In Linux environments, compiling and executing programs is routine for development. However, adversaries exploit this by compiling malicious code to establish reverse shells, enabling remote control. The detection rule identifies this threat by monitoring sequences of compilation, execution, and network activity, flagging unusual connections that deviate from typical patterns, thus indicating potential compromise.

### Possible investigation steps

- Review the process execution details to identify the compiler used (e.g., gcc, g++, cc) and examine the arguments passed during the compilation to understand the nature of the compiled code.
- Investigate the file creation event associated with the linker (ld) to determine the output executable file and its location on the system.
- Analyze the subsequent process execution to identify the newly compiled executable and verify its legitimacy by checking its hash against known malware databases.
- Examine the network connection attempt details, focusing on the destination IP address, to determine if it is associated with known malicious activity or command-and-control servers.
- Check the process name involved in the network connection attempt to ensure it is not a commonly used legitimate process, as specified in the query exclusions (e.g., simpleX, conftest, ssh, python, ispnull, pvtui).
- Correlate the timing of the compilation, execution, and network connection events to assess if they align with typical user behavior or indicate suspicious activity.

### False positive analysis

- Development activities involving frequent compilation and execution of new code can trigger false positives. To manage this, exclude specific user accounts or directories commonly used for legitimate development work.
- Automated build systems or continuous integration pipelines may compile and execute code regularly. Identify and exclude these processes or IP addresses from monitoring to prevent false alerts.
- Legitimate software updates or installations that involve compiling source code can be mistaken for malicious activity. Exclude known update processes or package managers from the rule.
- Network connections to internal or trusted IP addresses that are not part of the typical exclusion list might be flagged. Update the exclusion list to include these trusted IP ranges.
- Certain legitimate applications that compile and execute code as part of their normal operation, such as IDEs or scripting environments, should be identified and excluded from the rule to reduce noise.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified in the alert, especially those related to the recently compiled executable and any associated network connections.
- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or scheduled tasks.
- Remove any malicious executables or scripts identified during the investigation from the system to prevent re-execution.
- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""

[[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.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

[[rule.threat.technique]]
id = "T1095"
name = "Non-Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1095/"

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