Elastic rules: 0n

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

[rule]
author = ["Elastic"]
description = """
Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and
is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what
occurred during the logging gap.
"""
false_positives = [
    """
    Suspending the recording of a trail may be done by a system or network administrator. Verify whether the user
    identity, user agent, and/or hostname should be making changes in your environment. Trail suspensions 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 CloudTrail Log Suspended"
note = """## Triage and analysis

### Investigating AWS CloudTrail Log Suspended

AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.

#### Possible investigation steps
- **Actor & scope**
  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
  - Determine which trail stopped and whether it’s multi-region or organization-wide.
- **Timing and impact**
  - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap?
- **Correlate activity**
  - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes).
  - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`.

### False positive analysis
- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation.

### Response and remediation
- Restart logging (`StartLogging`) immediately.
- Investigate actor’s recent activity; rotate credentials if suspicious.
- Validate trail configuration, destination bucket/CMK, and event selectors.
- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs.

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_StopLogging.html",
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/stop-logging.html",
]
risk_score = 73
rule_id = "1aa8fa52-44a7-4dae-b058-f3333b91c8d7"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Cloudtrail",
    "Use Case: Log Auditing",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "query"

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


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

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

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

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[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",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with
"BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile
(CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS
silently provisions a "BedrockAPIKey-<id>" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is
intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console
access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's
Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is
revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there
is no legitimate workflow that produces it.
"""
false_positives = [
    """
    There is no known legitimate workflow that adds IAM access keys or console login profiles to a Bedrock API key phantom
    user. Any match should be investigated. Confirm the actor in "aws.cloudtrail.user_identity.arn" and the target user in
    "aws.cloudtrail.request_parameters", and remove the credential if it was not expected.
    """,
]
from = "now-30m"
language = "esql"
license = "Elastic License v2"
name = "AWS IAM Credentials Added to a Bedrock API Key Phantom User"
note = """## Triage and analysis

### Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User

Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-<id>" and attaches the AmazonBedrockLimitedAccess managed policy. That policy is broader than its name suggests: it grants Bedrock control-plane actions (including deletion of guardrails, custom models, and provisioned throughput) as well as IAM, VPC, and KMS reconnaissance. The phantom user is meant only to back the bearer token and should never hold standard access keys or an interactive console login.

Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step.

### Possible investigation steps

- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator.
- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile).
- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins).
- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline.

### False positive analysis

- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise.

### Response and remediation

- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential.
- Review the actor's recent activity and rotate or restrict its credentials.
- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to block this pivot organization-wide.
"""
references = [
    "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response",
    "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html",
]
risk_score = 73
rule_id = "71159cad-f8b3-4b3c-ac6e-9cab05594670"
setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
| WHERE event.provider == "iam.amazonaws.com"
    AND event.action IN ("CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile")
    AND event.outcome == "success"
    AND user.target.name LIKE "BedrockAPIKey-*"
| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*
'''


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

[metadata]
creation_date = "2026/08/24"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/24"

[rule]
author = ["Elastic"]
description = """
Detects the first time an AWS identity requests a service quota increase via the AWS Service
Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support
and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and
other services. An adversary who obtains AWS credentials may request quota increases as
infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing
campaigns, or data exfiltration operations that require compute or network resources beyond
the account's current limits.
"""
false_positives = [
    """
    Cloud infrastructure teams requesting quota increases for planned capacity expansions,
    new region deployments, or scaling events will trigger this rule. Validate the requested
    service and limit against your infrastructure roadmap before closing.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Service Quota Increase Requested by Rare Identity"
note = """## Triage and analysis

### Investigating AWS Service Quota Increase Requested by Rare Identity

AWS Service Quotas (formerly Service Limits) cap how many resources of each type an account can create. Default limits exist to prevent accidental runaway provisioning, but an adversary who requests an increase can scale operations far beyond what the default limits allow: requesting 1000 EC2 On-Demand vCPUs enables cryptomining at industrial scale; requesting higher SES sending limits enables large-scale phishing campaigns; requesting higher Lambda concurrency enables large-scale credential-stuffing operations.

### Possible investigation steps

- Identify the caller from aws.cloudtrail.user_identity.arn and user.name.
- Review aws.cloudtrail.request_parameters for the serviceCode (which AWS service), the quotaCode (which specific limit), and the requested value.
- Determine whether the requested quota increase aligns with a known infrastructure project.
- Check whether the same identity has recently created resources in the service being scaled (EC2 RunInstances, Lambda CreateFunction, SES SendEmail).
- Review whether this is the first quota increase request for this service from this identity or a continuation of a known capacity planning effort.

### Response and remediation

- If unauthorized, submit a cancellation request to AWS Support for the quota increase.
- Revoke active sessions for the requesting identity.
- Apply an SCP restricting servicequotas:RequestServiceQuotaIncrease to approved cloud-operations roles that require prior approval.
"""
references = [
    "https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_RequestServiceQuotaIncrease.html",
    "https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/",
]
risk_score = 47
rule_id = "7e1b0654-b6c0-4b1b-ab47-75588533083c"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Service Quotas management events are logged by default."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Service Quotas",
    "Rule Type: New Terms",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "servicequotas.amazonaws.com"
    and event.action: "RequestServiceQuotaIncrease"
    and event.outcome: "success"
    and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible* or "cloudformation.amazonaws.com")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1583"
name = "Acquire Infrastructure"
reference = "https://attack.mitre.org/techniques/T1583/"


[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id", "user.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/08/17"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/09/10"

[rule]
author = ["Elastic"]
description = """
Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not
the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a
LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt.
"""
false_positives = [
    """
    Custom configuration-management that decrypts CMS blobs with an organization key outside /var/lib/waagent. Confirm
    the key path and exclude the specific command line after review.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation"
note = """## Triage and analysis

### Investigating Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation

CyberCX-style WireServer abuse on Linux generates `openssl req -x509 -subj /CN=LinuxTransport`, posts the public
certificate to WireServer `comp=certificates`, then runs `openssl cms -decrypt` or `openssl smime -decrypt` with
`temp.key`, `wireserver.key`, or another non-waagent key to unwrap protectedSettings.

Benign Azure Linux Agent activity looks like:

`openssl cms -inform DER -decrypt -recip /var/lib/waagent/<thumbprint>.crt -inkey /var/lib/waagent/<thumbprint>.prv`

The Azure Linux Agent is excluded by certificate path in process arguments (`/var/lib/waagent/*`) and by
parent executables `/usr/sbin/waagent` and `/usr/bin/waagent`. This does not exclude Python or
`run-command-extension` as parents because attacker scripts invoked via Run Command use those parents
with a non-waagent key. The agent itself also runs `openssl req ... /CN=LinuxTransport` with output
under `/var/lib/waagent/`; that argument path exclusion covers it.

### Possible investigation steps

- Review `process.command_line` and `process.args` for `LinuxTransport`, `wireserver.key`, `temp.key`, `payload.p7m`,
  or `payload.pfx`.
- Inspect parent and grandparent: Run Command (`/var/lib/waagent/run-command/`) or an interactive shell is higher
  risk than a one-off admin session with a ticket.
- Correlate with network events from curl to `168.63.129.16` ports 80 and 32526 on the same host.
- Search StorageRead logs for anonymous or SAS GetBlob of the same storage account after the decrypt.
- Hunt for the generated key files (`temp.key`, `wireserver.key`) on disk and in `/tmp`.

### False positive analysis

- The Azure Linux Agent decrypt path under `/var/lib/waagent/` and waagent parent executables
  (`/usr/sbin/waagent`, `/usr/bin/waagent`) are excluded.
- Legitimate certificate tooling that uses `-subj /CN=LinuxTransport` is unexpected; treat as suspicious until proven
  otherwise.

### Response and remediation

- Isolate the VM, delete attacker-generated keys and decrypted payloads, and rotate secrets that were in
  protectedSettings (SAS, connection strings, CSE script contents).
- Rotate the VM managed identity and review extension configuration.
- Revoke any SAS that was replayed from the decrypted settings.
"""
references = [
    "https://cybercx.com.au/blog/azure-ssrf-metadata/",
    "https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/",
    "https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services",
    "https://gtfobins.github.io/gtfobins/openssl/",
]
risk_score = 47
rule_id = "5bb27863-2da6-4d0d-879a-1efb10479c39"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Cloud",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Platform: Azure",
    "Platform: Linux",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start") and process.name == "openssl" and
(
  (
    process.args in ("cms", "smime") and process.args == "-decrypt"
  ) or
  (
    process.args == "req" and process.args : "*LinuxTransport*"
  )
) and
not process.args like "/var/lib/waagent/*" and
not process.parent.executable like (
  "/usr/sbin/waagent",
  "/usr/bin/waagent"
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[rule.threat.technique.subtechnique]]
id = "T1552.005"
name = "Cloud Instance Metadata API"
reference = "https://attack.mitre.org/techniques/T1552/005/"



[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"


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

[rule]
description = """
Identifies a delayed load of the Microsoft Common Language Runtime DLL CLR.dll associated with egress network
connections.
"""
id = "44fa18bd-c484-48f0-84ea-b8fd7d0586aa"
license = "Elastic License v2"
name = "Delayed Common Language Runtime Load"
os_list = ["windows"]
version = "1.0.6"

query = '''
sequence by process.entity_id with maxspan=5s 
 [network where process.pid != 4 and
   event.action in ("disconnect_received", "connection_attempted") 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.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") and 
    not process.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe", "\\Device\\Mup\\*") and
     not (process.code_signature.trusted == true and
          process.code_signature.subject_name : 
                     ("Flexera Software LLC", "Dassault Systemes SolidWorks Corp.", "Adaptive Protocols, Inc.", "SAP SE", "HP Inc.", 
                      "TechSmith Corporation", "FactSet Research Systems Inc.", "Corel Corporation", "Amazon.com Services LLC", "Commvault Systems, Inc.",
                      "ONELAUNCH TECHNOLOGIES INC.", "REFINITIV US LLC", "Corel Corporation", "Environmental Systems Research Institute, Inc.",
                      "Nox Limited", "Therefore Corporation GmbH", "Autodesk, Inc.", "National Instruments Corporation", "Siemens AG",
                      "The Reynolds and Reynolds Company"))
    ]
 [library where dll.name : ("clr.dll", "mscorwks.dll") and process.uptime >= 1 and 
  process.thread.Ext.call_stack_summary : "ntdll.dll|*mscoreei.dll*" and
  not process.thread.Ext.call_stack_summary : 
                           ("*mscoreei.dll|msi*.tmp|msi.dll*", 
                            "*|mscoreei.dll|mscoree.dll*", 
                            "*mscoreei.dll|combase.dll*", 
                            "*pghook.dll|mscoreei.dll|previewview.dll*",
                            "*mscoreei.dll|microsoft.teams.addinloader.dll*",
                            "*mscoreei.dll|vstoloader.dll*",
                            "*mscoreei.dll|onelaunch*.tmp|*",
                            "*mscoreei.dll|utils.dll|gencls.dll*",
                            "*mscoreei.dll|revupreviewhandler.dll*",
                            "*mscoreei.dll|previewview.dll*",
                            "*mscoreei.dll|twuniclitsprintx64.dll|rdclientax.dll*")]
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.8.0"

[metadata]
creation_date = "2026/01/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/02/09"

[rule]
author = ["Elastic"]
description = """
Detects executable file downloads via wget to suspicious locations such as /tmp or /Users/Shared. Threat 
actors commonly use wget to download malicious payloads and additional tools for post-exploitation.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*", "logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Executable File Download via Wget"
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 Executable File Download via Wget

This rule detects wget pulling down a Mach-O executable and writing it into commonly abused transient or shared directories on macOS, which often signals payload staging during ingress tool transfer. Attackers frequently run wget from a shell or scripted installer to fetch a second-stage binary into /tmp or /Users/Shared, then immediately execute it to establish command and control or deploy additional tooling.

### Possible investigation steps

- Pivot from the detected wget process to identify its parent process, user context, and full command line to determine whether it was launched by an interactive shell, script, or installer package.  
- Review the network connection details from the wget execution (remote IP/domain, URL path, TLS certificate/SNI if available) and assess reputation plus whether it aligns with known internal software distribution.  
- Inspect the downloaded Mach-O at the destination path by collecting its hash, signature/notarization status, and basic static traits (strings, embedded URLs, ad-hoc signing) to quickly judge legitimacy.  
- Check for immediate follow-on activity from the same host such as execution of the new file, creation of persistence (LaunchAgents/Daemons, cron, login items), or additional tool downloads within the next few minutes.  
- Scope for reuse by searching across endpoints for the same downloaded hash, filename, URL, or destination directory pattern to determine blast radius and whether this is a recurring delivery mechanism.

### False positive analysis

- An administrator or developer uses wget in a script to fetch an internal build or test Mach-O binary and stages it in /tmp or /Users/Shared for immediate execution during troubleshooting or CI-style workflows.  
- A legitimate installation or update routine invokes wget to download a helper executable to a transient directory (for unpacking or preflight checks) before moving it into an application bundle, causing a short-lived write to /tmp-like paths.

### Response and remediation

- Isolate the affected macOS host from the network and terminate the active `wget` process to stop additional payload transfers or execution.  
- Quarantine the downloaded Mach-O from `/tmp`, `/private/tmp`, `/var/tmp`, or `/Users/Shared` and preserve a copy plus the originating `wget` command/URL for analysis before removal.  
- Hunt on the host for immediate follow-on execution of the downloaded file and remove any persistence artifacts created around the same time, such as new LaunchAgents/LaunchDaemons, login items, or cron entries pointing to the staged path.  
- Block the observed download URL/domain/IP at egress controls and add allowlisting controls for approved internal distribution sources to reduce future misuse of `wget` for tool transfer.  
- Escalate to incident response if the staged Mach-O is executed, unsigned/ad-hoc signed, establishes outbound connections to unapproved infrastructure, or the same hash/URL is found on multiple endpoints.  
- Harden endpoints by restricting `wget` usage where possible, enforcing Gatekeeper/notarization and least-privilege execution, and adding monitoring/controls for executable writes and executions from world-writable directories.
"""
references = [
    "https://attack.mitre.org/techniques/T1105/"
]
risk_score = 47
rule_id = "36755b43-a1f9-4f2c-9b61-6b240dd0e164"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id with maxspan=30s
  [network where host.os.type == "macos" and event.type == "start" and process.name == "wget"]
  [file where host.os.type == "macos" and event.action == "modification" and 
    process.name == "wget" and 
    file.path like ("/tmp/*", "/private/tmp/*", "/private/var/tmp/*", "/var/tmp/*", "/Users/Shared/*") and
    file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*")]
'''

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

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

  [[rule.threat.technique]]
  name = "Ingress Tool Transfer"
  id = "T1105"
  reference = "https://attack.mitre.org/techniques/T1105/"

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

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

  [[rule.threat.technique]]
  name = "User Execution"
  id = "T1204"
  reference = "https://attack.mitre.org/techniques/T1204/"

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

[rule]
description = """
Identifies the creation or execution of a Windows script via a Windows Management Instrumentation Script consumer. The
ActiveScriptEventConsumer class runs a predefined script in an arbitrary scripting language when an event is delivered
to it. This is a legit feature but rarely used and can be a sign of execution or persistence via a malicious WMI Script
consumer.
"""
id = "396f3062-05ba-4594-b83e-9bd6597f0e5e"
license = "Elastic License v2"
name = "Execution via WMI ActiveScript Event Consumer"
os_list = ["windows"]
reference = [
    "https://threathunterplaybook.com/hunts/windows/200902-RemoteWMIActiveScriptEventConsumers/notebook.html",
    "https://learn.microsoft.com/en-us/windows/win32/wmisdk/activescripteventconsumer",
]
version = "1.0.12"

query = '''
process where event.action == "start" and
 (
  process.parent.executable : "?:\\Windows\\Sys*\\wbem\\scrcons.exe" or
  descendant of [process where event.action == "start" and process.executable : "?:\\Windows\\Sys*\\wbem\\scrcons.exe"] or
  (process.pe.original_file_name : "wmic.exe" and process.command_line : "*create*" and process.command_line : "*ActiveScriptEventConsumer*")
  ) and
  not (process.executable : "?:\\Windows\\System32\\wscript.exe" and
       user.id : "S-1-5-18" and process.args : "?:\\Windows\\System32\\sleeper.vbs") and
  not process.executable :
              ("?:\\Program Files\\*.exe",
               "?:\\Program Files (x86)\\*.exe",
               "?:\\Windows\\System32\\gpupdate.exe",
               "?:\\Windows\\Microsoft.NET\\Framework64\\v*\\ngen.exe",
               "?:\\Windows\\Microsoft.NET\\Framework64\\v*\\ngentask.exe")  and
  not (process.executable : "?:\\Windows\\System32\\schtasks.exe" and
       process.args : "\"C:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\CCXProcess.exe\"") and
  not (process.executable : "?:\\Windows\\System32\\omadmprc.exe" and user.id : "S-1-5-18") and process.parent.executable != null and
  not (process.executable : "?:\\Windows\\system32\\conhost.exe" and process.args : "0xffffffff" and process.args : "-ForceV1") and
  not process.hash.sha256 :
                   ("4620eaed30bea5f44b2655df1592f2d3cfc45042f513876090c30153a3e23815",
                    "0e9a6b9d0481a0f9aa49e6f53bc87414ecb84a6d45ef301f6abfde07a8e894a4",
                    "0f635ffad292ec796dec18cafe896f09168ad2cdefec4fc8530a6a538db21e54",
                    "d13f5e3d679ffb5787eb0227741cf3e3e3b476a831742e086c1aebea15acf735",
                    "ac3e1f40ce7bb7e31f9f2804fdc495ac566c5c072d850c66525926ca18fa7a27",
                    "5c9382277658a46d9918c81b760b0e7caea3639266bcdda68413ac63f9ad6f68") and
  not process.parent.executable :
                     ("?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\libs\\node.exe",
                      "?:\\Program Files (x86)\\Google\\GoogleUpdater\\*\\updater.exe")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1047"
name = "Windows Management Instrumentation"
reference = "https://attack.mitre.org/techniques/T1047/"

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

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



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

[internal]
min_endpoint_version = "7.16.0"

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by
exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data
exfiltration.
"""
false_positives = [
    """
    Netcat is a dual-use tool that can be used for benign or malicious activity. Netcat is included in some Linux
    distributions so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may
    originate from scripts, automation tools, and frameworks.
    """,
]
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "File Transfer or Listener Established via Netcat"
note = """## Triage and analysis

### Investigating File Transfer or Listener Established via Netcat

Netcat is a dual-use command line tool that can be used for various purposes, such as port scanning, file transfers, and connection tests. Attackers can abuse its functionality for malicious purposes such creating bind shells or reverse shells to gain access to the target system.

A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing.

A bind shell is a type of backdoor that attackers set up on the target host and binds to a specific port to listen for an incoming connection from the attacker.

This rule identifies potential reverse shell or bind shell activity using Netcat by checking for the execution of Netcat followed by a network connection.

#### Possible investigation steps

- Examine the command line to identify if the command is suspicious.
- Extract and examine the target domain or IP address.
  - Check if the domain is newly registered or unexpected.
  - Check the reputation of the domain or IP address.
  - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.

### False positive analysis

- Netcat is a dual-use tool that can be used for benign or malicious activity. It is included in some Linux distributions, so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Block the identified indicators of compromise (IoCs).
- Take actions to terminate processes and connections used by the attacker.
- 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 = [
    "http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet",
    "https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf",
    "https://en.wikipedia.org/wiki/Netcat",
    "https://www.hackers-arise.com/hacking-fundamentals",
    "https://null-byte.wonderhowto.com/how-to/hack-like-pro-use-netcat-swiss-army-knife-hacking-tools-0148657/",
    "https://levelup.gitconnected.com/ethical-hacking-part-15-netcat-nc-and-netcat-f6a8f7df43fd",
]
risk_score = 47
rule_id = "adb961e0-cb74-42a0-af9e-29fc41f88f5f"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

### 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).

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name in ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") and
process.args like~ (
  /* bind shell to specific port or listener */
  "-*l*","-*p*",
  /* reverse shell to command-line interpreter used for command execution */
  "-*e*",
  /* file transfer via stdout/pipe */
  ">","<", "|"
)
'''

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

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

[[rule.threat.technique]]
id = "T1048"
name = "Exfiltration Over Alternative Protocol"
reference = "https://attack.mitre.org/techniques/T1048/"

[[rule.threat.technique.subtechnique]]
id = "T1048.003"
name = "Exfiltration Over Unencrypted Non-C2 Protocol"
reference = "https://attack.mitre.org/techniques/T1048/003/"

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

[metadata]
creation_date = "2026/02/23"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/04/08"

[rule]
author = ["Elastic"]
description = """
Detects the first time a Python process creates or modifies a LaunchAgent or LaunchDaemon plist file on a given host.
Malicious Python scripts, compromised dependencies, or model file deserialization can establish persistence on macOS by
writing plist files to LaunchAgent or LaunchDaemon directories. Legitimate Python processes do not typically create
persistence mechanisms, so a first occurrence is a strong indicator of compromise.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Python Created a LaunchAgent or LaunchDaemon"
note = """## Triage and analysis

### Investigating First Time Python Created a LaunchAgent or LaunchDaemon

macOS LaunchAgents and LaunchDaemons are plist files that configure programs to run automatically at login or boot. Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — can drop plist files to establish persistence on the compromised host. This ensures their payload survives reboots and user logouts.

This rule uses the Elastic Defend persistence event type (`event.action:"launch_daemon"`), which captures plist metadata including the program arguments, run-at-load configuration, and keep-alive settings. The New Terms rule type alerts on the first time a Python process creates a LaunchAgent or LaunchDaemon on a given host within a 7-day window.

### Possible investigation steps

- Review the persistence event fields (`Persistence.runatload`, `Persistence.keepalive`, `Persistence.args`, `Persistence.path`) to understand the plist configuration.
- Examine the program path and arguments specified in the plist to determine if they reference a known legitimate application or a suspicious binary.
- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency.
- Verify if the target binary referenced in the plist exists on disk and whether it is signed or trusted.
- Investigate the origin of any recently downloaded scripts, packages, or model files on the host.
- Check for other persistence mechanisms that may have been established around the same time.

### False positive analysis

- Some Python-based system management tools (e.g., Ansible, SaltStack) may legitimately create LaunchAgent or LaunchDaemon plist files. Evaluate whether the activity matches a known automation workflow.
- Python-based application installers may create plist files during setup. Check if the activity correlates with a known software installation.

### Response and remediation

- Immediately unload the suspicious LaunchAgent or LaunchDaemon using `launchctl unload` with the plist path.
- Remove the suspicious plist file and any associated binary it references.
- Kill any processes launched by the plist file.
- Investigate and quarantine the Python script, package, or model file that created the persistence mechanism.
- Scan the host for additional indicators of compromise.
- If a malicious file is confirmed, identify all hosts where it may have been distributed.
"""
references = [
    "https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/",
    "https://github.com/trailofbits/fickling",
]
risk_score = 47
rule_id = "25368123-b7b8-4344-9fd4-df28051b4c6e"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
    "Domain: LLM",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
host.os.type:macos and event.action:"launch_daemon" and
process.name:python*
'''

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

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

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

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

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["host.id", "file.path"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a Virtual Private Cloud (VPC) network is deleted in Google Cloud Platform (GCP). A VPC network is a
virtual version of a physical network within a GCP project. Each VPC network has its own subnets, routes, and firewall,
as well as other elements. An adversary may delete a VPC network in order to disrupt their target's network and business
operations.
"""
false_positives = [
    """
    Virtual Private Cloud networks may be deleted by system administrators. Verify that the 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 Virtual Private Cloud Network Deletion"
note = """## Triage and analysis

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

### Investigating GCP Virtual Private Cloud Network Deletion

Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes.

### Possible investigation steps

- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion.
- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe.
- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse.
- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected.
- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network.
- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks.

### False positive analysis

- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools.
- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise.
- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers.

### Response and remediation

- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications.
- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized.
- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime.
- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery.
- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future.

## 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/vpc"]
risk_score = 47
rule_id = "c58c3081-2e1d-4497-8491-e73a45d1a6d6"
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:v*.compute.networks.delete and event.outcome:success
'''


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

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

[[rule.threat.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/"

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

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

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

[metadata]
creation_date = "2026/06/30"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/06/30"

[rule]
author = ["Elastic"]
description = """
Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process
communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded.
"""
false_positives = [
    """
    Administrators may enable hostIPC for legitimate debugging. Exclude trusted users or namespaces after baselining.
    """,
]
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Pod Created With HostIPC"
note = """## Triage and analysis

### Investigating GKE Pod Created With HostIPC

Host IPC lets a pod interact with host IPC facilities. Review the pod spec, actor, and whether the change was expected.

### Investigation steps

- Confirm `gcp.audit.request.spec.hostIPC` and targeted namespace or pod.
- Review `user.email` and correlate with other risky pod modifications.

### False positives

- Break-glass debugging on nodes; allowlist known admin identities.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://kubernetes.io/docs/concepts/security/pod-security-standards/",
    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
]
risk_score = 47
rule_id = "fde4efad-9cd0-4fa4-84c8-0e3b6fc957b4"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.outcome:success and
event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and
gcp.audit.request.spec.hostIPC:true and
not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
'''

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

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

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

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

[metadata]
creation_date = "2023/08/30"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt
secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and
"bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Linux Process Hooking via GDB"
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 Linux Process Hooking via GDB

GDB, the GNU Debugger, is a powerful tool used for debugging applications by inspecting their memory and execution flow. Adversaries can exploit GDB to attach to running processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious use of GDB by monitoring process initiation with specific arguments, flagging potential unauthorized memory access attempts for further investigation.

### Possible investigation steps

- Review the process details to confirm the presence of GDB by checking if the process name is "gdb" and the arguments include "--pid" or "-p".
- Identify the target process that GDB is attempting to attach to by examining the process arguments and cross-referencing the process ID.
- Investigate the user account under which the GDB process is running to determine if it is authorized to perform debugging tasks on the target process.
- Check the system logs and audit logs for any unusual activity or prior attempts to access sensitive processes or data around the time the GDB process was initiated.
- Correlate the event with other security alerts or anomalies in the environment to assess if this is part of a broader attack pattern or isolated incident.
- Evaluate the necessity and legitimacy of the GDB usage in the context of the system's normal operations and the user's role.
- If unauthorized access is suspected, consider isolating the affected system and conducting a deeper forensic analysis to prevent potential data exfiltration.

### False positive analysis

- Development and debugging activities may trigger the rule when developers use GDB for legitimate purposes. To manage this, create exceptions for specific user accounts or development environments where GDB usage is expected.
- Automated scripts or maintenance tasks that utilize GDB for process inspection can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule.
- Security tools or monitoring solutions that use GDB for legitimate process analysis might be flagged. Verify these tools and whitelist their processes or execution contexts to prevent unnecessary alerts.
- Training or educational environments where GDB is used for learning purposes can lead to false positives. Consider excluding these environments or specific user groups from the rule to avoid interference with educational activities.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate the GDB process if it is confirmed to be unauthorized, using process management tools to stop the process safely.
- Conduct a memory dump analysis of the affected system to identify any potential data leakage or extraction of sensitive information.
- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities.
- Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use.
- Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
risk_score = 21
rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
 and process.name == "gdb" and process.args in ("--pid", "-p") and
/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
process.args != "1"
'''


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

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

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

[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 = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"

[[rule.threat.technique.subtechnique]]
id = "T1055.008"
name = "Ptrace System Calls"
reference = "https://attack.mitre.org/techniques/T1055/008/"

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

[metadata]
creation_date = "2022/01/10"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the occurrence of files uploaded to SharePoint being detected as Malware by the file scanning engine.
Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their
access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities
to gain initial access to other endpoints in the environment.
"""
false_positives = ["Benign files can trigger signatures in the built-in virus protection"]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 SharePoint Malware File Detected"
note = """## Triage and analysis

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

### Investigating M365 SharePoint Malware File Detected

SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats.

### Possible investigation steps

- Review the specific event details in the alert, focusing on the event.dataset, event.provider, event.code, and event.action fields to confirm the alert is related to a SharePoint file upload flagged as malware.
- Identify the user account associated with the file upload by examining the audit logs and determine if the account has a history of suspicious activity or if it has been compromised.
- Analyze the file metadata, including the file name, type, and size, to gather more context about the nature of the uploaded file and assess its potential impact.
- Check the file's sharing permissions and access history to identify other users or systems that may have interacted with the file, assessing the risk of lateral movement.
- Investigate the source of the file upload, such as the originating IP address or device, to determine if it aligns with known malicious activity or if it is an anomaly for the user.
- Coordinate with the IT team to isolate affected systems or accounts if necessary, and initiate a response plan to mitigate any potential spread of the malware within the organization.

### False positive analysis

- Legitimate software updates or patches uploaded to SharePoint may be flagged as malware. To handle this, create exceptions for known update files by verifying their source and hash.
- Internal security tools or scripts used for testing purposes might trigger false positives. Maintain a list of these tools and exclude them from alerts after confirming their legitimacy.
- Files with encrypted content, such as password-protected documents, can be mistakenly identified as malicious. Implement a process to review and whitelist these files if they are from trusted sources.
- Large batch uploads from trusted departments, like IT or HR, may occasionally be flagged. Establish a review protocol for these uploads and whitelist them if they are verified as safe.
- Files with macros or executable content used in legitimate business processes might be detected. Work with relevant departments to identify and exclude these files from alerts after thorough validation.

### Response and remediation

- Immediately isolate the affected SharePoint site or library to prevent further access and sharing of the malicious file. This can be done by restricting permissions or temporarily disabling access to the site.
- Notify the security operations team and relevant stakeholders about the detected malware to ensure awareness and initiate a coordinated response.
- Quarantine the identified malicious file to prevent it from being accessed or executed by users. Use SharePoint's built-in capabilities or integrated security tools to move the file to a secure location.
- Conduct a thorough scan of the affected SharePoint site and connected systems to identify any additional malicious files or indicators of compromise. Use advanced threat detection tools to ensure comprehensive coverage.
- Review and revoke any unauthorized access or sharing permissions that may have been granted to the malicious file, ensuring that only legitimate users have access to sensitive data.
- Escalate the incident to the incident response team if there are signs of lateral movement or if the malware has spread to other parts of the network, following the organization's escalation protocols.
- Implement enhanced monitoring and logging for SharePoint and related services to detect any future attempts to upload or share malicious files, leveraging the specific query fields used in the detection rule.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide",
]
risk_score = 73
rule_id = "0e52157a-8e96-4a95-a6e3-5faae5081a74"
severity = "high"
tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:SharePoint and event.code:SharePointFileOperation and event.action:FileMalwareDetected
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1080"
name = "Taint Shared Content"
reference = "https://attack.mitre.org/techniques/T1080/"


[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1608"
name = "Stage Capabilities"
reference = "https://attack.mitre.org/techniques/T1608/"
[[rule.threat.technique.subtechnique]]
id = "T1608.001"
name = "Upload Malware"
reference = "https://attack.mitre.org/techniques/T1608/001/"


[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

[metadata]
creation_date = "2026/01/20"
integration = ["suricata"]
maturity = "production"
updated_date = "2026/02/17"

[rule]
author = ["Elastic"]
description = """
This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history.
Analysts can use this to prioritize triage and response.
"""
from = "now-7205m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Newly Observed High Severity Suricata Alert"
risk_score = 99
rule_id = "d591d7af-399b-4888-b705-ae612690c48d"
severity = "critical"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Domain: Network", "Data Source: Suricata"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-suricata.*

  // high severity alerts
| where event.module == "suricata" and event.kind == "signal" and event.severity == 1 and
        rule.name is not null and
        not rule.name like "SURICATA STREAM*"

| STATS Esql.alerts_count = count(*),
        Esql.first_time_seen = MIN(@timestamp),
        Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),
        Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),
        src_ip_values = VALUES(source.ip),
        dst_ip_values = VALUES(destination.ip),
        url_dom = VALUES(url.domain),
        url_path = VALUES(url.path) by rule.name, event.type

| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
  // first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and
// exclude high volume alerts such as vuln-scanners
  Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2

// move dynamic fields to ECS quivalent for rule exceptions
| eval source.ip = MV_FIRST(src_ip_values),
       destination.ip = MV_FIRST(dst_ip_values),
       url.domain = MV_FIRST(url_dom),
       url.path = MV_FIRST(url_path)
| keep rule.name, event.type, Esql.*, source.ip, destination.ip, url.domain, url.path
'''
note = """## Triage and analysis

### Investigating Newly Observed High Severity Suricata Alert

This rule surfaces newly observed, low-frequency high severity suricata alerts within the last 5 days.

Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
whether it represents a true compromise or rare benign activity.

### Investigation Steps

- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert.
- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.
- Refer to the specific alert details like event.original to get more context.

### False Positive Considerations

- Vulnerability scanners and pentesting.
- Administrative scripts or automation tools can trigger detections when first introduced.
- Development or testing environments may produce one-off behaviors that resemble malicious techniques.

### Response and Remediation

- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
- Terminate malicious processes and remove any dropped files or persistence mechanisms.
- Collect forensic artifacts to understand initial access and execution flow.
- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
- If benign, document the finding and consider tuning or exception handling to reduce future noise.
- Continue monitoring the host and environment for recurrence of the behavior or related alerts."""
references = ["https://www.elastic.co/docs/reference/integrations/suricata"]

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation or modification of a DirectoryService PlugIns (dsplug) file. The DirectoryService daemon
launches on each system boot and automatically reloads after crash. It scans and executes bundles that are located in
the DirectoryServices PlugIns folder and can be abused by adversaries to maintain persistence.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Persistence via DirectoryService Plugin Modification"
references = ["https://blog.chichou.me/2019/11/21/two-macos-persistence-tricks-abusing-plugins/"]
risk_score = 47
rule_id = "89fa6cb7-6b53-4de2-b604-648488841ab8"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
file where host.os.type == "macos" and event.action == "modification" and
  file.path like "/Library/DirectoryServices/PlugIns/*.dsplug"
'''
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 Persistence via DirectoryService Plugin Modification

DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on system boot. Adversaries exploit this by modifying or creating malicious plugins to ensure persistent access. The detection rule identifies suspicious activity by monitoring non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized modifications indicative of persistence tactics.

### Possible investigation steps

- Review the alert details to confirm the file path matches /Library/DirectoryServices/PlugIns/*.dsplug, indicating a potential unauthorized modification or creation of a DirectoryService plugin.
- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other system events or user activities around that time.
- Investigate the file's origin by examining the file's metadata, such as the creator or modifying user, and cross-reference with known user accounts and their typical behavior.
- Analyze the contents of the modified or newly created dsplug file to identify any malicious code or unusual configurations that could indicate adversarial activity.
- Review system logs and other security alerts around the time of the event to identify any related suspicious activities or patterns that could suggest a broader compromise.
- Assess the risk and impact of the modification by determining if the plugin is actively being used for persistence or if it has been executed by the DirectoryService daemon.

### False positive analysis

- Routine system updates or legitimate software installations may modify dsplug files, triggering alerts. Users can create exceptions for known update processes or trusted software installations to reduce noise.
- Administrative tasks performed by IT personnel, such as configuring directory services, might involve legitimate modifications to dsplug files. Implementing a whitelist for actions performed by verified IT accounts can help minimize false positives.
- Security software or system management tools that interact with directory services might cause benign modifications. Identifying and excluding these tools from monitoring can prevent unnecessary alerts.
- Automated scripts or maintenance tasks that regularly check or update directory service configurations could be flagged. Documenting and excluding these scripts from detection can help maintain focus on genuine threats.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Conduct a thorough review of the identified dsplug file(s) in the /Library/DirectoryServices/PlugIns/ directory to confirm unauthorized modifications or creations. Compare against known good configurations or backups.
- Remove any unauthorized or malicious dsplug files and restore legitimate versions from a trusted backup if available.
- Restart the DirectoryService daemon to ensure it is running only legitimate plugins. This can be done by executing `sudo launchctl stop com.apple.DirectoryServices` followed by `sudo launchctl start com.apple.DirectoryServices`.
- Perform a comprehensive scan of the system using updated security tools to identify any additional malicious files or indicators of compromise.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring on the DirectoryServices PlugIns directory to detect future unauthorized changes promptly, ensuring alerts are configured to notify the security team immediately."""


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

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

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

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

[metadata]
creation_date = "2025/10/01"
integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/07/17"

[rule]
author = ["Elastic"]
description = """
Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path,
consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an
attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.file*",
    "logs-sentinel_one_cloud_funnel.*",
    "endgame-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential CVE-2025-32463 Nsswitch File 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 Potential CVE-2025-32463 Nsswitch File Creation

This rule flags creation of an nsswitch.conf file outside the standard /etc location by a shell, an early sign of staging a fake root to coerce sudo's chroot path and hijack NSS resolution (CVE-2025-32463). A common pattern is writing /tmp/chroot/etc/nsswitch.conf, placing or pointing to a malicious NSS module, then running sudo chroot into that directory so name lookups load attacker-controlled code and escalate to root.

### Possible investigation steps

- Correlate the event with any sudo or chroot executions within ±10 minutes that reference the same directory prefix (e.g., /tmp/chroot), capturing full command line, user, TTY, working directory, and exit codes.
- Inspect the created nsswitch.conf for nonstandard services or module names and enumerate any libnss_*.so* under lib*/ or usr/lib*/ within that prefix, recording owner, hashes, and timestamps.
- List all contemporaneous file writes under the same prefix (etc, lib*, bin, sbin) to determine whether a chroot rootfs is being assembled and attribute it to a toolchain such as tar, rsync, debootstrap, or custom scripts via process ancestry.
- Search file access telemetry to see whether privileged processes subsequently read that specific nsswitch.conf or loaded libnss_* from the same path, which would indicate the chroot was exercised.
- Verify sudo and glibc versions and patch status for CVE-2025-32463 and collect the initiating user’s session context (SSH source, TTY, shell history) to assess exploitability and scope.

### False positive analysis

- An administrator legitimately staging a temporary chroot or test root filesystem may use a shell to create /tmp/*/etc/nsswitch.conf while populating configs, matching the rule even though no privilege escalation is intended.
- OS installation, recovery, or backup-restore workflows run from a shell can populate a mounted target like /mnt/newroot/etc/nsswitch.conf, creating the file outside /etc as part of maintenance and triggering the alert.

### Response and remediation

- Terminate any sudo or chroot processes referencing the created path (e.g., /tmp/chroot/etc/nsswitch.conf), lock the initiating user’s sudo access, and quarantine the parent directory with root-only permissions.
- Remove the staged nsswitch.conf and any libnss_*.so* or ld.so.* artifacts under lib*/ or usr/lib*/ within that prefix after collecting copies, hashes, and timestamps for evidence.
- Restore and verify /etc/nsswitch.conf on the host with correct content and root:root 0644, purge temporary chroot roots under /tmp, /var/tmp, or /mnt, and restart nscd or systemd-resolved to flush cached name-service data.
- Escalate to incident response if sudo chroot was executed against the same directory, if root processes loaded libnss_* from that path, or if nsswitch.conf appears outside /etc on multiple hosts within a short window.
- Apply vendor fixes for CVE-2025-32463 to sudo and glibc, disallow chroot in sudoers and enforce env_reset, noexec, and secure_path, and mount /tmp and /var/tmp with noexec,nosuid,nodev to prevent libraries being sourced from user-writable paths.
- Add controls to block execution from user-created chroot trees by policy (AppArmor or SELinux) and create alerts on creation of */etc/nsswitch.conf or libnss_* writes under non-system paths, with auto-isolation for directories under /tmp or a user’s home.
"""
references = [
    "https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot",
    "https://github.com/kh4sh3i/CVE-2025-32463",
]
risk_score = 73
rule_id = "163a8f2f-c8a0-4b7e-9c4a-1184310eb7f3"
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 = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Use Case: Vulnerability",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and file.path like "/*/etc/nsswitch.conf" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not 
(
  process.name in ("bash", "dash") and file.path like (
    "/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*", "/tmp/petalinux*/etc/nsswitch.conf",
    "/tmp/selfextract.*/mkinitramfs_*/etc/nsswitch.conf", "/var/tmp/dracut.*/initramfs/etc/nsswitch.conf",
    "/tmp/user/0/mkinitramfs_*/etc/nsswitch.conf", "/opt/mkinitramfs_*/etc/nsswitch.conf",
    "/opt/dumpling-nxp/*/etc/nsswitch.conf", "/tmp/store/vfs/dir/*", "/opt/tmp/mkinitramfs_*",
    "/opt/nvidia_tmpfs/mkinitramfs*"
  )
)
'''

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

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

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

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

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

[rule]
description = """
Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is
possible with local administrator privileges and is commonly referred to as a NetNTLMv1 downgrade attack.
"""
id = "6179bd21-a2ca-40c0-bfef-77aab4e99432"
license = "Elastic License v2"
name = "Potential NetNTLMv1 Downgrade Attack"
os_list = ["windows"]
reference = [
    "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level",
]
version = "1.0.4"

query = '''
registry where event.action == "modification" and registry.value == "LmCompatibilityLevel" and registry.data.strings in ("2", "1", "0") and
/* noisy FP - need to be compensated by a detection rule */
not (user.id == "S-1-5-18" and process.name == "powershell.exe" and registry.data.strings in ("1", "0"))
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Identifies the use of known legit utilities to potentially tunnel network traffic. This can be used by attackers to
enable routing of network packets that would otherwise not reach their intended destination.
"""
id = "87aa3f52-3f7b-4d6e-aecc-101bb1275020"
license = "Elastic License v2"
name = "Potential Protocol Tunneling via Legit Utilities"
os_list = ["windows"]
reference = ["https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/"]
version = "1.0.12"

query = '''
process where event.action == "start" and
 (
  /* RDP port and usual SSH tunneling related switches in command line */
  (process.command_line : "*:3389*" and process.args : ("-L", "-P", "-R", "-pw", "-ssh")) or

  (process.code_signature.subject_name : "ngrok, Inc." and process.args : ("http", "tcp", "tunnel", "tls", "start", "3389")) or

  (process.executable : "?:\\Windows\\System32\\OpenSSH\\ssh.exe" and process.command_line : ("*127.0.0.*", "*:localhost:*") and process.args : "-L") or

  (process.args : "client" and process.command_line : "* R*:socks*") or

  ((process.name : "curl.exe" or process.pe.original_file_name == "curl.exe") and process.command_line : ("*socks5h://127.0.0.*", "*socks5h:\\127.0.0.*"))
 )
and not (process.code_signature.subject_name : "ninjaRMM LLC" and process.code_signature.status : "trusted") and
not (process.name:"ssh.exe" and process.args in ("22000:127.0.0.1:1466", "localhost:8897:localhost:8897", "22000:127.0.0.1:1466",
                                                 "10005:localhost:5050", "localhost:8897:localhost:8897", "59000:localhost:5901",
                                                 "-L30000:localhost:30000", "7779:localhost:7779", "5000:localhost:5000",
                                                 "8888:localhost:8888")) and
not process.parent.command_line : ("C:\\windows\\system32\\cmd.exe /c \"\"C:\\Users\\*\\Desktop\\*.bat\" \"",
                                   "\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" ",
                                   "C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"


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

[internal]
min_endpoint_version = "7.15.0"