Elastic rules: 38

[metadata]
creation_date = "2024/11/04"
integration = ["aws"]
maturity = "production"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.3.0"
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This
behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a
compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to
gain a better understanding of the target's infrastructure.
"""
false_positives = [
    """
    Administrators or automated systems may legitimately perform multiple `Describe`, `List`, `Get` and `Generate` API
    calls in a short time frame. Verify the user identity and the purpose of the API calls to determine if the behavior
    is expected.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS Discovery API Calls via CLI from a Single Resource"
note = """## Triage and analysis

### Investigating AWS Discovery API Calls via CLI from a Single Resource

This rule detects when a single AWS identity executes more than five unique discovery-related API calls (`Describe*`, `List*`, `Get*`, or `Generate*`) within a 10-second window using the AWS CLI.  
High volumes of diverse “read-only” API calls in such a short period can indicate scripted reconnaissance, often an early phase of compromise after credential exposure or access to a compromised EC2 instance.  

### Possible investigation steps

**Identify the actor and session context**
- **Actor ARN (`aws.cloudtrail.user_identity.arn`)**: Determine which IAM user, role, or service principal performed the actions.  
  - Check whether this identity normally performs enumeration activity or belongs to automation infrastructure.  
- **Identity type (`Esql.aws_cloudtrail_user_identity_arn_type`)**: Validate if the caller is a human IAM user, assumed role, or federated identity. Unusual types (e.g., temporary credentials from an unfamiliar role) may indicate lateral movement.  
- **Access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`)** – Identify which specific access key or temporary credential was used.  
  - If multiple suspicious keys are found, use AWS IAM console or `aws iam list-access-keys` to determine when they were last used or rotated.  
- **Account (`Esql.cloud_account_id_values`)** – Confirm which AWS account was affected and whether it matches the intended operational context (e.g., production vs. sandbox).

**Assess the API call pattern and intent**
- **Distinct action count (`Esql.event_action_count_distinct`)**: Note how many unique API calls occurred within each 10-second window. Counts far above normal operational baselines may indicate scripted reconnaissance.  
- **API actions (`Esql.event_action_values`)**: Review which discovery APIs were invoked.  
  - Focus on services such as EC2 (`DescribeInstances`), IAM (`ListRoles`, `ListAccessKeys`), S3 (`ListBuckets`), and KMS (`ListKeys`), which adversaries frequently query to map assets.  
- **Service providers (`Esql.event_provider_values`)**: Identify which AWS services were targeted.  
  - Multi-service enumeration (IAM + EC2 + S3) suggests broad discovery rather than a specific diagnostic task.  
- **Time window (`Esql.time_window_date_trunc`)**: Verify whether activity occurred during normal maintenance windows or outside expected hours.

**Analyze the source and origin**
- **Source IP (`Esql.source_ip_values`)**: Check the originating IPs to determine whether the calls came from a known internal host, an EC2 instance, or an unfamiliar external network.  
  - Compare with known corporate CIDR ranges, VPC flow logs, or guardrail baselines.  
- **Source organization (`Esql.source_as_organization_name_values`)**: Review the associated ASN or organization.  
  - If the ASN belongs to a commercial ISP or VPN service, investigate possible credential compromise or remote attacker usage.

**Correlate with additional events**
- Search CloudTrail for the same `aws.cloudtrail.user_identity.arn` or `aws_cloudtrail_user_identity_access_key_id_values` within ±30 minutes.  
  - Look for follow-on actions such as `GetCallerIdentity`, `AssumeRole`, `CreateAccessKey`, or data access (`GetObject`, `CopySnapshot`).  
  - Correlate this enumeration with authentication anomalies or privilege-related findings.  
- Cross-reference `Esql.cloud_account_id_values` with other alerts for lateral or privilege escalation patterns.

### False positive analysis

Legitimate, high-frequency API activity may originate from:
- **Inventory or compliance automation**: Scripts or tools such as AWS Config, Cloud Custodian, or custom CMDB collection performing periodic Describe/List calls.  
- **Operational monitoring systems**: DevOps pipelines, Terraform, or deployment verifiers enumerating resources.  
- **Security tooling**: Security scanners performing asset discovery across services.

Validate by confirming:
- Whether the `aws.cloudtrail.user_identity.arn` corresponds to a documented automation or monitoring identity.  
- That the observed `Esql.event_action_values` match known inventory or cost-reporting workflows.  
- Timing alignment with approved maintenance schedules.

### Response and remediation

If the activity is unexpected or originates from unrecognized credentials, follow AWS’s incident-handling guidance:

**Contain**
- Temporarily disable or rotate the access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`) using IAM.  
- Restrict outbound connectivity for the instance or resource from which the API calls originated.

**Investigate**
- Retrieve full CloudTrail logs for the actor and `Esql.time_window_date_trunc` interval.  
- Identify any subsequent write or privilege-modification actions.  
- Review associated IAM policies for excessive permissions.

**Recover and Harden**
- Rotate credentials, enforce MFA on human users, and tighten IAM role trust policies.  
- Implement AWS Config rules or SCPs to monitor and restrict large-scale enumeration.

**Post-Incident Actions**
- Document the finding and response in your organization’s IR management system.  
- Update detection logic or allow-lists for known benign automation.  
- Validate recovery by confirming no new suspicious discovery bursts occur.

### Additional information

- **AWS Documentation**
  - [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html)
  - [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf)
- **AWS Playbook Resources**
  - [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks)
  - [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework)

"""
references = [
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/",
    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
]
risk_score = 21
rule_id = "74f45152-9aee-11ef-b0a5-f661ea17fbcd"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: AWS EC2",
    "Data Source: AWS IAM",
    "Data Source: AWS S3",
    "Data Source: AWS Cloudtrail",
    "Data Source: AWS RDS",
    "Data Source: AWS Lambda",
    "Data Source: AWS STS",
    "Data Source: AWS KMS",
    "Data Source: AWS SES",
    "Data Source: AWS Cloudfront",
    "Data Source: AWS DynamoDB",
    "Data Source: AWS Elastic Load Balancing",
    "Data Source: AWS Organizations",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws.cloudtrail-* metadata _id, _version, _index
// create time window buckets of 10 seconds
| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)

| where
    data_stream.dataset == "aws.cloudtrail"
    
    // exclude service account and console behavior
    and source.ip IS NOT NULL
    and aws.cloudtrail.session_credential_from_console IS NULL
    and event.provider in (
      "iam.amazonaws.com",
      "ec2.amazonaws.com",
      "s3.amazonaws.com",
      "rds.amazonaws.com",
      "lambda.amazonaws.com",
      "dynamodb.amazonaws.com",
      "kms.amazonaws.com",
      "cloudfront.amazonaws.com",
      "elasticloadbalancing.amazonaws.com", 
      "cloudtrail.amazonaws.com",
      "sts.amazonaws.com",
      "ses.amazonaws.com",
      "organizations.amazonaws.com"
    )
    // ignore AWS service actions
    and aws.cloudtrail.user_identity.type != "AWSService"
    // filter for aws-cli specifically
    and user_agent.name == "aws-cli"
    // exclude DescribeCapacityReservations events related to AWS Config
    and event.action != "DescribeCapacityReservations"
    and user.name != "AWSServiceRoleForConfig"

// filter for Describe, Get, List, and Generate API calls
| where true in (
    starts_with(event.action, "Describe"),
    starts_with(event.action, "Get"),
    starts_with(event.action, "List"),
    starts_with(event.action, "Generate")
)

// keep relevant fields (preserving ECS fields and computed time window)
| keep 
    @timestamp, 
    Esql.time_window_date_trunc, 
    event.action, 
    aws.cloudtrail.user_identity.arn, 
    aws.cloudtrail.user_identity.type, 
    aws.cloudtrail.user_identity.access_key_id, 
    source.ip, 
    cloud.account.id, 
    event.provider, 
    user_agent.name, 
    source.as.organization.name, 
    cloud.region,
    data_stream.namespace

// count the number of unique API calls per time window and actor
| stats
    Esql.event_action_count_distinct = count_distinct(event.action),
    Esql.event_action_values = VALUES(event.action),
    Esql.event_timestamp_values = VALUES(@timestamp),
    Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type),
    Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id),
    Esql.source_ip_values = VALUES(source.ip),
    Esql.cloud_account_id_values = VALUES(cloud.account.id),
    Esql.event_provider_values = VALUES(event.provider),
    Esql.user_agent_name_values = VALUES(user_agent.name),
    Esql.source_as_organization_name_values = VALUES(source.as.organization.name),
    Esql.cloud_region_values = VALUES(cloud.region),
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn

// filter for more than 5 unique API calls per 10s window
| where Esql.event_action_count_distinct > 5

| keep
    aws.cloudtrail.user_identity.arn,
    Esql.time_window_date_trunc,
    Esql.event_action_count_distinct,
    Esql.event_action_values,
    Esql.event_timestamp_values,
    Esql.aws_cloudtrail_user_identity_type_values,
    Esql.aws_cloudtrail_user_identity_access_key_id_values,
    Esql.source_ip_values,
    Esql.cloud_account_id_values,
    Esql.event_provider_values,
    Esql.user_agent_name_values,
    Esql.source_as_organization_name_values,
    Esql.cloud_region_values,
    Esql.data_stream_namespace_values
'''


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


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

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


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

[rule.investigation_fields]
field_names = [
    "Esql.event_action_count_distinct",
    "Esql.time_window_date_trunc",
    "aws.cloudtrail.user_identity.arn",
    "Esql.aws_cloudtrail_user_identity_type_values",
    "Esql.aws_cloudtrail_user_identity_access_key_id_values",
    "Esql.source_ip_values",
    "Esql.source_as_organization_name_values",
    "Esql.event_provider_values",
    "Esql.event_action_values",
    "Esql.event_timestamp_values",
    "Esql.cloud_account_id_values",
    "Esql.cloud_region_values",
    "Esql.data_stream_namespace_values",
]

[metadata]
creation_date = "2020/11/04"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies unusual processes connecting to domains using known free SSL certificates. Adversaries may employ a known
encryption algorithm to conceal command and control traffic.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-endpoint.events.network-*", "logs-windows.sysmon_operational-*"]
language = "eql"
license = "Elastic License v2"
name = "Connection to Commonly Abused Free SSL Certificate Providers"
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 Connection to Commonly Abused Free SSL Certificate Providers

Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.

### Possible investigation steps

- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\\Windows\\System32\\*.exe" and "C:\\Windows\\SysWOW64\\*.exe".
- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service.
- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign.
- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity.
- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.

### False positive analysis

- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise.
- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates.
- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening.
- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily.
- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections.
- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise.
- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated.
- Restore the system from a known good backup if any critical system files or configurations have been altered.
- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
risk_score = 21
rule_id = "e3cf38fa-d5b8-46cc-87f9-4a7513e4281d"
setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Sysmon Event ID 22 - DNS Query](https://ela.st/sysmon-event-22-setup)
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where host.os.type == "windows" and network.protocol == "dns" and
  /* Add new free SSL certificate provider domains here */
  dns.question.name : ("*letsencrypt.org", "*.sslforfree.com", "*.zerossl.com", "*.freessl.org") and

  /* Native Windows process paths that are unlikely to have network connections to domains secured using free SSL certificates */
  process.executable : ("C:\\Windows\\System32\\*.exe",
                        "C:\\Windows\\System\\*.exe",
	                  "C:\\Windows\\SysWOW64\\*.exe",
		          "C:\\Windows\\Microsoft.NET\\Framework*\\*.exe",
		          "C:\\Windows\\explorer.exe",
		          "C:\\Windows\\notepad.exe") and

  /* Insert noisy false positives here */
  not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1573"
name = "Encrypted Channel"
reference = "https://attack.mitre.org/techniques/T1573/"


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

[metadata]
creation_date = "2026/01/21"
integration = ["cloud_defend", "kubernetes"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct
interactive Kubernetes API requests. An adversary may need to execute direct interactive Kubernetes API requests to gain
access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate
the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within
the cluster. Note that this rule may not trigger if the authorization token of the request is expanded within the process
argument list, as the length of the "process.args" field may lead to the field being ignored.
"""
false_positives = [
    """
    There is a potential for false positives if the direct interactive Kubernetes API requests are used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
    """
    There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
    to the wrong container.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*", "logs-kubernetes.audit_logs-*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Direct Interactive Kubernetes API Request by Common Utilities"
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 Direct Interactive Kubernetes API Request by Common Utilities

This detection links an interactive invocation of common networking utilities or kubectl inside a container to a near-simultaneous Kubernetes API response, indicating hands-on-keyboard access to the API server for discovery or lateral movement. A common attacker pattern is compromising a pod, reading its mounted service account token, then running curl or kubectl interactively to query /api or /apis endpoints to list pods and secrets and map cluster scope.

### Possible investigation steps

- From Kubernetes audit logs linked to the pod, capture the authenticated principal, namespace, verbs, and request URIs to determine whether the activity focused on discovery or sensitive resources like secrets or RBAC objects.
- Correlate the interactive container activity with kubelet exec/attach or terminal session telemetry to identify who initiated the session and through which source IP or control-plane endpoint.
- Inspect the pod’s service account by validating access to the mounted token path and enumerating its RoleBindings and ClusterRoleBindings to quantify effective privileges and decide on immediate revocation or rotation.
- Review the container image provenance and available shell history or command logs to confirm use of networking utilities or kubectl and identify any reads of secrets, kubeconfig files, or /api and /apis endpoints.
- Expand the time window to find prior or subsequent API calls from the same pod, namespace, or node, and quarantine or cordon the workload if you observe sustained enumeration or cross-namespace access.

### False positive analysis

- An operator uses kubectl exec -it to enter a pod and runs kubectl or curl to list resources or verify RBAC, producing interactive process starts and near-simultaneous Kubernetes audit responses that are expected during troubleshooting.
- During routine connectivity or certificate checks, an engineer attaches to a container that includes curl/openssl/socat/ncat and interactively tests the Kubernetes API server endpoint, generating correlated audit events without malicious intent.

### Response and remediation

- Immediately isolate the implicated pod by terminating the interactive shell and curl/kubectl processes, applying a deny-all NetworkPolicy in its namespace, and temporarily blocking pod egress to the kube-apiserver address.
- Revoke and rotate the service account credentials used by the pod, invalidate the token at /var/run/secrets/kubernetes.io/serviceaccount/token, and remove excess RoleBindings or ClusterRoleBindings tied to that identity.
- Delete and restore the workload from a trusted image that excludes curl/wget/openssl/socat/ncat, with automountServiceAccountToken disabled and least-privilege RBAC enforced.
- Escalate to incident response if the pod read Secrets or ConfigMaps, modified RBAC objects, attempted create/patch/delete on cluster-scoped resources, or originated from an unapproved operator workstation or bastion.
- Harden by restricting kubectl exec/attach to a small admin group with MFA, enabling admission controls (Pod Security Admission, Gatekeeper, or Kyverno) to block shells or kubectl/netcat in images, and applying egress NetworkPolicies so only approved namespaces can reach https://kubernetes.default.svc.
"""
risk_score = 47
rule_id = "9d312839-339a-4e10-af2e-a49b15b15d13"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Data Source: Kubernetes",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
     process.name in ("wget", "curl", "openssl", "socat", "ncat", "kubectl") or
     (
       /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
       process.args in (
         "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget",
         "ssl_client", "/bin/ssl_client", "/usr/bin/ssl_client", "/usr/local/bin/ssl_client",
         "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl",
         "openssl", "/bin/openssl", "/usr/bin/openssl", "/usr/local/bin/openssl",
         "socat", "/bin/socat", "/usr/bin/socat", "/usr/local/bin/socat",
         "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
         "kubectl", "/bin/kubectl", "/usr/bin/kubectl", "/usr/local/bin/kubectl"
       ) and
       /* default exclusion list to not FP on default multi-process commands */
       not process.args in (
         "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
         "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
         "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
         "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
       )
     )
   ) and process.interactive == true and container.id like "*"
  ] by orchestrator.resource.name
  [any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted")] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name` 
'''

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

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

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

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

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

[metadata]
creation_date = "2026/06/22"
integration = ["azure"]
maturity = "production"
updated_date = "2026/06/22"

[rule]
author = ["Elastic"]
description = """
Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph
token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced,
for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional
Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one
application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to
any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary
holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for
example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the
overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as
"success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional
Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced
grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not
enforced while the single-factor, password-only sign-in still succeeded.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN"
note = """## Triage and analysis

### Investigating Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN

This rule fires the first time a user signs in to Microsoft Graph through a Microsoft first-party app using single-factor, password-only authentication, keyed on the user, app, and source ASN within the history window. First-party apps are matched by their owner tenant (`app_owner_tenant_id` `f8cdef31-a31e-4b4a-93e4-5f571e91255a`) instead of a fixed client ID list, so switching to a different first-party client does not get around the detection. The password-only form of this bypass depends on first-party apps: they are pre-consented in every tenant and cannot be blocked, so a stolen password is enough to use one. A third-party or confidential client would mean the attacker already controls an app in the tenant, which is a different scenario.

The behavior comes from the Conditional Access resource-exclusion bypass. If an "all resources" CA policy excludes even one application, Entra ID issues tokens for baseline scopes (User.Read, openid, profile, email) to Microsoft Graph without applying the policy's grant controls, so MFA is skipped. Default directory permissions then let that `User.Read` token read groups, service principals, directory roles, and devices.

Do not read too much into the top-level `azure.signinlogs.properties.conditional_access_status` here. It shows `success` or `notApplied` (never `failure`, since the sign-in is not blocked), and which one you see depends on the other policies in the tenant. The useful evidence is in `azure.signinlogs.properties.applied_conditional_access_policies`: an MFA grant control (`enforced_grant_controls` of `Mfa`) that came back `notApplied` on a sign-in that was still single-factor and password-based. That is what the query keys on.

### Possible investigation steps

- Review `azure.signinlogs.properties.user_principal_name` to identify the user and whether they hold privileged roles or are otherwise a high-value target.
- Confirm the client via `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id`. End-user authentication of clients such as Microsoft Bing Search to Microsoft Graph is uncommon and warrants scrutiny; everyday clients (Microsoft Teams, OneDrive, Outlook Mobile) are far more likely to be benign.
- Examine `source.ip`, `source.as.number`, `source.as.organization.name`, and `source.geo.*` for hosting-provider or geographic anomalies inconsistent with the user's normal sign-in locations.
- Inspect `azure.signinlogs.properties.applied_conditional_access_policies` for the sign-in. A policy with `enforced_grant_controls` of `Mfa` and a `result` of `notApplied`, on a `singleFactorAuthentication` / `Password` sign-in, means the MFA grant control was present but not enforced. Note the aggregate `conditional_access_status` may read `success` or `notApplied` and is not by itself indicative.
- Review whether the tenant has an "all resources" Conditional Access policy with one or more application exclusions, which is the configuration that enables this bypass.
- Pivot to `logs-azure.graphactivitylogs-*` for the same `user_principal_object_id` and `app_id` to identify directory enumeration (requests to `/groups`, `/servicePrincipals`, `/directoryRoles`, `/devices`, `/users`) shortly after the sign-in.
- Correlate using `azure.signinlogs.properties.session_id` to reconstruct the full token-acquisition sequence, including any non-interactive token redemption.

### False positive analysis

- Everyday first-party public clients (Microsoft Teams, OneDrive, Outlook Mobile, Microsoft 365 Copilot, Microsoft To-Do, Edge, Windows Search) legitimately acquire Microsoft Graph tokens with single-factor authentication, particularly when MFA was already satisfied earlier in the session or no MFA policy applies to that application. Expect benign first-time `(user, app, ASN)` combinations, especially during onboarding or first use of a tool.
- Users signing in from a new network (travel, VPN, new ISP) will present a new ASN and may trigger the New Terms condition once.
- In tenants with broad MFA Conditional Access policies, those policies can legitimately report `notApplied` for single-factor sign-ins that are genuinely out of policy scope (for example, sign-ins from a trusted named location or an app excluded from the policy). The `applied_conditional_access_policies` condition therefore sharpens, but does not perfectly isolate, the bypass; corroborate with the application identity and source.
- The rule scopes to all Microsoft first-party applications via `app_owner_tenant_id` rather than a fixed client ID list, so it covers every first-party public client but is correspondingly broad. New Terms on `(user, app_id, ASN)` limits this to first-occurrence events; consider allowlisting expected `(user, app)` pairs, or specific high-volume everyday first-party apps, to further reduce volume.
- Tune by excluding known developer or automation identities that routinely use these clients against Microsoft Graph.

### Response and remediation

- Contact the user to confirm whether they initiated the sign-in and used the detected application.
- If unauthorized, revoke the user's refresh tokens and require password reset and MFA re-registration.
- Review `logs-azure.graphactivitylogs-*` for directory enumeration or data access performed with the issued token.
- Remediate the enabling configuration: review "all resources" Conditional Access policies for application exclusions, and enable strict baseline-scope enforcement so baseline scopes do not bypass grant controls.
- Block the source IP or ASN if confirmed malicious.
"""
references = [
    "https://dirkjanm.io/bypassing-conditional-access-with-resource-exclusion/",
    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
]
risk_score = 47
rule_id = "921544bd-e2aa-44a6-9fb9-98629c342adf"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and
azure.signinlogs.properties.conditional_access_status: ("success" or "notApplied") and
azure.signinlogs.properties.authentication_details.authentication_method: "Password" and
azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls: "Mfa" and
azure.signinlogs.properties.applied_conditional_access_policies.result: "notApplied" and
(
    azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000" or
    azure.signinlogs.properties.resource_display_name: "Microsoft Graph"
) and
azure.signinlogs.properties.app_owner_tenant_id: "f8cdef31-a31e-4b4a-93e4-5f571e91255a" and
azure.signinlogs.properties.user_principal_name: * and
azure.signinlogs.properties.app_id: * and
source.as.number: *
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"
[[rule.threat.technique.subtechnique]]
id = "T1556.009"
name = "Conditional Access Policies"
reference = "https://attack.mitre.org/techniques/T1556/009/"



[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 = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.resource_id",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.authentication_requirement",
    "azure.signinlogs.properties.conditional_access_status",
    "azure.signinlogs.properties.applied_conditional_access_policies.display_name",
    "azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls",
    "azure.signinlogs.properties.applied_conditional_access_policies.result",
    "azure.signinlogs.properties.is_interactive",
    "azure.signinlogs.properties.session_id",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "source.geo.country_name",
    "user_agent.original",
]

[rule.new_terms]
field = "new_terms_fields"
value = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.app_id",
    "source.as.number",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[rule]
author = ["Elastic"]
description = """
Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker authenticates is using a user agent 
that is not consistent with common browser, mobile, or Windows platform authentication clients. Adversary-in-the-middle and OAuth phishing
tooling often presents scripted or relayed user agents (for example Node.js, Python, or generic HTTP libraries) while
still targeting first-party resources through the broker.
"""
false_positives = [
    """
    Legitimate automation, SDKs, or custom applications that obtain tokens through the Microsoft Authentication Broker
    against Graph, Azure AD, or Device Registration Service may use non-browser user agents. Baseline approved
    service principals, managed identities, and developer tooling before tuning exclusions for known automation
    patterns.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent"
note = """## Triage and analysis

### Investigating Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent

Review `azure.signinlogs.properties.user_principal_name`, `user_agent.original`,
`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and
`source.as.organization.name`.

Confirm whether the user or application intentionally used a non-browser client against the requested resource.

### Possible investigation steps

- Inspect `user_agent.original` for automation libraries (for example `node`, `axios`, `python-requests`, `curl`).
- Correlate `azure.signinlogs.properties.session_id` with other sign-ins, device registration audit events, or Graph
  activity in the same time window.
- Review conditional access outcomes and identity protection signals for the user.
- Compare `source.ip` and ASN against expected VPN, MDM, and developer egress.

### False positive analysis

- Microsoft platform and mobile clients using Mozilla-, Dalvik-, CFNetwork-, or Windows-AzureAD-Authentication-Provider-
  style user agents are excluded by design.
- First-party CLI tools and test harnesses that legitimately broker tokens may still match if they use uncommon user
  agent strings.

### Response and remediation

- If malicious, revoke refresh tokens for the user, review newly registered devices, and reset credentials per policy.
- Escalate when paired with suspicious ASN sign-ins, multi-IP OAuth flows, or follow-on Graph data access.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
    "https://any.run/malware-trends/tycoon/",
]
risk_score = 73
rule_id = "c22f89d9-b674-4650-8454-02242c8b35eb"
severity = "high"
setup = """
Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must populate `user_agent.original`,
`azure.signinlogs.properties.app_display_name`, and `azure.signinlogs.properties.resource_display_name`.
"""
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and event.outcome:(success or Success) and 
(azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" or azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e") and
user_agent.original:(* and not (Mozilla* or Dalvik* or *CFNetwork* or Windows-AzureAD-Authentication-Provider* or Java*ThinkPad*)) and
azure.signinlogs.properties.resource_display_name:*
'''

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

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

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

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

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"

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

[rule]
description = """
Identifies when a program is loading DNGUard DLL (DNGuard HVM is a .NET obfuscator and code protector), this may
indicate an attempt to bypass static detection by obfuscating malicious code.
"""
id = "e691d379-6d01-43cc-9f1e-ab10df48a6bc"
license = "Elastic License v2"
name = "Execution of a DNGUard Protected Program"
os_list = ["windows"]
reference = ["https://attack.mitre.org/techniques/T1027/002/", "http://www.dnguard.net/products.php"]
version = "1.0.23"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) and
  not process.executable : "?:\\Program Files (x86)\\Digiarty\\WinX MediaTrans\\MediaTrans.exe"]
  [library where
   (dll.name :"HVMRuntm.dll" or
    dll.hash.sha256 :"a0b11444c5913bc048c2f97b670cc801176df17565c48d6e7a30fef651ca8426" or
    dll.pe.imphash : "b2ff0f091ba14e9fe411060ab1560c66")]
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"
[[threat.technique.subtechnique]]
id = "T1027.002"
name = "Software Packing"
reference = "https://attack.mitre.org/techniques/T1027/002/"



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

[internal]
min_endpoint_version = "8.4.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies execution via MSSQL xp_cmdshell stored procedure. Malicious users may attempt to elevate their privileges by
using xp_cmdshell, which is disabled by default, thus, it's important to review the context of it's use.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "kuery"
license = "Elastic License v2"
name = "Execution via MSSQL xp_cmdshell Stored Procedure"
note = """## Triage and analysis

### Investigating Execution via MSSQL xp_cmdshell Stored Procedure

Microsoft SQL Server (MSSQL) has procedures meant to extend its functionality, the Extended Stored Procedures. These procedures are external functions written in C/C++; some provide interfaces for external programs. This is the case for xp_cmdshell, which spawns a Windows command shell and passes in a string for execution. Attackers can use this to execute commands on the system running the SQL server, commonly to escalate their privileges and establish persistence.

The xp_cmdshell procedure is disabled by default, but when used, it has the same security context as the MSSQL Server service account, which is often privileged.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- 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, registry or file modifications, and any spawned child processes.
- Examine the command line to determine if the command executed is potentially harmful or malicious.
- Inspect the host for suspicious or abnormal behavior in the alert timeframe.

### False positive analysis

- This mechanism can be used legitimately, but it brings inherent risk. The security team must monitor any activity of it. If recurrent tasks are being executed using this mechanism, consider adding exceptions — preferably with a full command line.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Remove and block malicious artifacts identified during triage.
- 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.
- Ensure that SQL servers are not directly exposed to the internet. If there is a business justification for such, use an allowlist to allow only connections from known legitimate sources.
- Disable the xp_cmdshell stored procedure.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

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

references = ["https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/"]
risk_score = 47
rule_id = "4ed493fc-d637-4a36-80ff-ac84937e5461"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:windows and event.category:process and event.type:start and
process.parent.name:"sqlservr.exe" and process.command_line : * and
(
  (
    (process.name.caseless : "cmd.exe" or process.pe.original_file_name : "Cmd.Exe") and
    not process.args : (
          \\\\* or diskfree or rmdir or mkdir or dir or DIR or del or rename or bcp or md or ren or REN or send or echo or
          ECHO or TYPE or type or EXIST or forfiles or sqlcmd or SQLCMD or dtexec or Sort-Object or cat or copy or COPY or
          move or MOVE or CD\\ or show or rd or powercfg or "C:\SPAN4\DATA\RISKPARAM.SPN" or ("@ECHO" and "@FOR") or
          ("@echo" and "@for") or (SET and PATH=*) or ("-ExecutionPolicy" and "-File") or MSSQLFDLauncher$DATEV_DBENGINE or
          (wmic and (cpu or computersystem or logicaldisk or os or ComputerSystem or volume)) or -s\:C\:\\WINDOWS\\SERVIC* or
          D\:\\* or E\:\\* or F\:\\* or Z\:\\* or "C:\Program Files\Amazon\AWSCLIV2\aws.exe" or C\:\\7-Zip\\7z.exe* or
          C\:\\FTP* or *\(Get-Item* or C\:\\ProgramData\\Daktronics*
    ) and
    not process.command_line : (
          "\"C:\\Windows\\system32\\cmd.exe\" /c " or
          "\"C:\\Windows\\System32\\cmd.exe\""
    )
  ) or
  process.name.caseless:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or
  process.name:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or
  process.pe.original_file_name:("CertUtil.exe" or "bitsadmin.exe" or "vpnbridge.exe")
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"
[[rule.threat.technique.subtechnique]]
id = "T1505.001"
name = "SQL Stored Procedures"
reference = "https://attack.mitre.org/techniques/T1505/001/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"



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

[rule.new_terms]
field = "new_terms_fields"
value = ["host.id", "process.command_line"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected an Exploit. Click the Elastic Endgame icon in the event.module column or the link in the
rule.reference column for additional information.
"""
from = "now-2m"
index = ["endgame-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Exploit - Detected - Elastic Endgame"
risk_score = 73
rule_id = "2003cdc8-8d83-4aa5-b132-1f9a8eb48514"
setup = """## Setup

### Additional notes

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

query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
'''
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 Exploit - Detected - Elastic Endgame

Elastic Endgame is a security solution that monitors and detects exploit attempts within an environment. Adversaries exploit vulnerabilities to execute unauthorized code or escalate privileges. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events. It leverages metadata and event actions to flag high-risk activities, aiding in swift threat detection and response.

### Possible investigation steps

- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to the Elastic Endgame detection.
- Examine the event.action and endgame.event_subtype_full fields to determine the specific exploit event type, which can provide insight into the nature of the exploit attempt.
- Investigate the endgame.metadata.type field to gather additional context about the detection, such as the source and target of the exploit attempt.
- Check the associated risk score and severity level to prioritize the investigation and response efforts, focusing on high-risk activities.
- Correlate the alert with other related events in the environment to identify potential patterns or additional indicators of compromise.
- Consult the MITRE ATT&CK framework for the Execution tactic (TA0002) to understand potential techniques that might have been used and to guide further investigation steps.

### False positive analysis

- Routine software updates or patches may trigger exploit detection alerts. Users can create exceptions for known update processes by identifying their unique metadata or event actions.
- Legitimate administrative tools that perform actions similar to exploits might be flagged. Users should whitelist these tools by specifying their event.module or event.action attributes.
- Automated scripts used for system maintenance could mimic exploit behavior. To prevent false positives, users can exclude these scripts by defining their specific endgame.event_subtype_full.
- Security testing activities, such as penetration tests, may generate alerts. Users can manage these by setting temporary exceptions during the testing period, based on the event.kind or event.module.

### Response and remediation

- Isolate the affected system immediately to prevent further exploitation or lateral movement within the network.
- Terminate any unauthorized processes identified as part of the exploit event to halt malicious activity.
- Apply relevant security patches or updates to the affected system to address the exploited vulnerability and prevent recurrence.
- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or secondary payloads.
- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts.
- Monitor the network for any signs of similar exploit attempts, using enhanced logging and alerting based on the identified threat indicators.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation."""


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

[[rule.threat.technique]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"

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

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

[metadata]
creation_date = "2023/10/26"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects the loading of a Linux kernel module through system calls. Threat actors may leverage Linux kernel modules to
load a rootkit on a system providing them with complete control and the ability to hide from security products. As other
rules monitor for the addition of Linux kernel modules through system utilities or .ko files, this rule covers the gap
that evasive rootkits leverage by monitoring for kernel module additions on the lowest level through auditd_manager.
"""
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "eql"
license = "Elastic License v2"
name = "Kernel Driver Load"
risk_score = 21
rule_id = "3e12a439-d002-4944-bc42-171c0dcb9b96"
setup = """## Setup
This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.

```
Kibana -->
Management -->
Integrations -->
Auditd Manager -->
Add Auditd Manager
```

`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.

For this detection rule to trigger, the following additional audit rules are required to be added to the integration:
```
-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
```

Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
"""
severity = "low"
tags = [
    "Data Source: Auditd Manager",
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
auditd.data.syscall in ("init_module", "finit_module")
'''
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 Kernel Driver Load

Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The 'Kernel Driver Load' detection rule leverages auditd to monitor system calls like `init_module`, identifying unauthorized module loads indicative of potential rootkit activity, thus enhancing threat detection and system integrity.

### Possible investigation steps

- Review the alert details to identify the specific host where the kernel module was loaded, focusing on the host.os.type field to confirm it is a Linux system.
- Examine the event.action field to verify that the action was indeed "loaded-kernel-module" and check the auditd.data.syscall field for the specific system call used, either "init_module" or "finit_module".
- Investigate the timeline of events on the affected host around the time of the alert to identify any suspicious activities or changes, such as new user accounts, unexpected network connections, or file modifications.
- Check the system logs and audit logs on the affected host for any additional context or anomalies that coincide with the module load event.
- Identify the source and legitimacy of the loaded kernel module by examining the module's file path, signature, and associated metadata, if available.
- Assess the potential impact and scope of the incident by determining if similar alerts have been triggered on other hosts within the environment, indicating a broader campaign or attack.

### False positive analysis

- Legitimate kernel module updates or installations can trigger alerts. Regularly scheduled updates or installations by trusted administrators should be documented and excluded from monitoring to reduce noise.
- System utilities that load kernel modules as part of their normal operation may cause false positives. Identify these utilities and create exceptions for their expected behavior.
- Automated configuration management tools that deploy or update kernel modules can generate alerts. Ensure these tools are recognized and their activities are whitelisted.
- Development environments where kernel modules are frequently compiled and tested may lead to frequent alerts. Exclude specific development hosts or processes from monitoring to avoid unnecessary alerts.
- Security software that loads kernel modules for protection purposes might be flagged. Verify and exclude these modules if they are from trusted vendors.

### Response and remediation

- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.
- Verify the legitimacy of the loaded kernel module by checking its source and integrity. If the module is unauthorized or suspicious, unload it using appropriate system commands.
- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to identify and remove any additional malicious components or rootkits.
- Review and analyze system logs, especially those related to auditd, to identify any unauthorized access or changes made by the adversary. This can help in understanding the scope of the compromise.
- Restore the system from a known good backup if the integrity of the system is in question and if the malicious activity cannot be fully remediated.
- Implement stricter access controls and monitoring on kernel module loading activities to prevent unauthorized actions in the future. This may include restricting module loading to trusted users or processes.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""


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

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

[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"

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

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

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

[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 = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"

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

[rule]
description = """
Identifies attempts to enumerate keystroke state using the Windows DirectInput API. Adversaries may log user keystrokes
to intercept credentials or other information from the user as the user types them.
"""
id = "102b5c1a-7f2a-4254-8b26-6b299705fce7"
license = "Elastic License v2"
name = "Keystroke Input Capture via DirectInput"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1056/001/",
    "https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee416842(v=vs.85)",
    "https://wikileaks.org/ciav7p1/cms/page_3375220.html",
    "https://www.elastic.co/security-labs/protecting-your-devices-from-information-theft-keylogger-protection",
]
version = "1.0.13"

query = '''
api where process.executable : "C:\\*" and 

 process.thread.Ext.call_stack_final_user_module.name : "dinput*.dll" and 
 
 (process.code_signature.exists == false or 
  process.code_signature.status == "errorBadDigest" or 
  process.code_signature.subject_name in ("The MathWorks, Inc.", "AutoIt Consulting Ltd", "Python Software Foundation") or 
  (process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Corporation") and process.executable : "?:\\Windows\\*" )) and 
  
  (process.Ext.api.name == "RegisterRawInputDevices" and
   process.Ext.api.parameters.usage == "KEYBOARD" and process.thread.Ext.call_stack_summary like "*|dinput?.dll|*") and 
   
  not process.executable : ("?:\\Windows\\System32\\dxdiag.exe", "?:\\Windows\\SysWOW64\\dxdiag.exe") and 
  not (process.executable : "?:\\Windows\\System32\\rundll32.exe" and 
       process.command_line : "?:\\WINDOWS\\system32\\rundll32.exe ?:\\WINDOWS\\system32\\inetcpl.cpl,ClearMyTracksByProcess*") and 
  not (process.executable : "?:\\Windows\\Sys*\\regsvr32.exe" and process.command_line : "*\\Program Files*\\LGHUB\\sdks\\sdk_legacy_steering_wheel*") and 
  not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", 
                            "?:\\Windows\\System32\\Macromed\\Flash\\FlashUtil_ActiveX.exe") and
  not process.thread.Ext.call_stack_summary like
              "wow64win.dll|wow64.dll|wow64cpu.dll|wow64.dll|ntdll.dll|win32u.dll|dinput8.dll|Unknown*"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1056"
name = "Input Capture"
reference = "https://attack.mitre.org/techniques/T1056/"
[[threat.technique.subtechnique]]
id = "T1056.001"
name = "Keylogging"
reference = "https://attack.mitre.org/techniques/T1056/001/"



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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2026/06/22"
integration = ["o365"]
maturity = "production"
updated_date = "2026/06/22"

[rule]
author = ["Elastic"]
description = """
Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member
profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams
external access to impersonate support personnel and socially engineer victims into granting remote access or
disclosing credentials.
"""
false_positives = [
    """
    Legitimate external partners or managed service providers with help desk-style display names may trigger this rule.
    Validate the sender tenant, domain, and business relationship before closing as benign.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Teams Rogue Help Desk Chat Created"
note = """## Triage and analysis

### Investigating M365 Teams Rogue Help Desk Chat Created

Threat actors create external Microsoft 365 tenants and initiate unsolicited one-on-one Teams chats while impersonating
IT help desk or Microsoft security personnel. These chats often precede vishing, Quick Assist abuse, or malicious link
delivery.

Review `user.email`, `user.domain`, `o365.audit.Members.DisplayName`, `o365.audit.ChatThreadId`, and
`o365.audit.ParticipantInfo`. Correlate follow-on `MessageSent` events for `source.ip` and `source.geo`, and
`CallParticipantDetail` events sharing the same `o365.audit.CallId` or chat thread for vishing activity.

#### Possible investigation steps

- Identify the external sender from `user.email`, `user.domain`, and `o365.audit.Members` and determine whether the
  tenant or domain is known and trusted.
- Compare `user.name` to `o365.audit.Members.DisplayName` — actors often use a lowercase mailbox alias such as
  `helpdesk` while presenting as `Help Desk` in Teams.
- Confirm `o365.audit.ParticipantInfo.HasForeignTenantUsers` is true and that no guest users are involved.
- Pivot on `o365.audit.ChatThreadId` for `MessageSent` and `CallParticipantDetail` events in the same session.
- Review `MessageSent` `source.ip` and `source.geo` for unexpected origin countries relative to the sender profile.
- Correlate with mail-flood, MFA fatigue, or URL click alerts for the targeted user in the same time window.
- Review whether the victim accepted the chat or responded, and hunt for follow-on remote support tool execution on
  their endpoint.
- Check whether the sender tenant appears newly created, trial-based, or otherwise anomalous for your environment.

### False positive analysis

- Approved external support vendors may use help desk-style display names. Maintain an allowlist of trusted external
  tenants or sender domains when recurring benign matches occur.
- The `user.email` and `user.name` impersonation clauses target external mailbox aliases such as `helpdesk@`. Prefer
  exceptions anchored on verified tenant IDs or sender domains rather than broad name-based exclusions.

### Response and remediation

- Warn the targeted user not to engage and confirm whether they accepted the chat or shared credentials.
- Block or restrict the external tenant via Teams federation policy if malicious.
- Hunt for additional `ChatCreated` events from the same external tenant across the organization.
- Review Teams external access settings and consider blocking trial tenants or restricting federation to an allowlist."""

references = [
    "https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/",
    "https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/",
]
risk_score = 73
rule_id = "e8e7b6b6-78b0-4015-97fe-c2f28468e0d4"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider:"MicrosoftTeams" and event.outcome:"success" and
  o365.audit.ParticipantInfo.HasOtherGuestUsers:false and o365.audit.ParticipantInfo.HasGuestUsers:false and
  o365.audit.ParticipantInfo.HasForeignTenantUsers:true and o365.audit.CommunicationType:"OneOnOne" and
  (
    o365.audit.Members:(
      "Help Desk" or "Help Desk Team" or "Help Desk IT" or "IT Help Desk" or
      "Microsoft Security" or "Microsoft  Security" or "Microsoft Support"
    ) or
    user.email:(
      *helpdesk* or *help.desk* or *help-desk* or *help_desk* or
      *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support*
    ) or
    user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport*)
  )
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user.email",
    "user.domain",
    "user.id",
    "o365.audit.Members",
    "o365.audit.Members.DisplayName",
    "o365.audit.ChatThreadId",
    "o365.audit.ResourceTenantId",
    "o365.audit.CommunicationType",
    "o365.audit.ParticipantInfo.HasForeignTenantUsers",
    "o365.audit.ParticipantInfo.HasGuestUsers",
    "o365.audit.ParticipantInfo.HasOtherGuestUsers",
    "o365.audit.ParticipantInfo.ParticipatingDomains",
    "event.action",
    "event.provider",
]

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

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

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

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

[metadata]
creation_date = "2020/05/20"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An
adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the
account.
"""
false_positives = [
    """
    If the behavior of deactivating MFA for Okta user accounts is expected, consider adding exceptions to this rule to
    filter false positives.
    """,
]
from = "now-12h"
index = ["logs-okta.system*"]
interval = "6h"
language = "eql"
license = "Elastic License v2"
name = "MFA Deactivation with no Re-Activation for Okta User Account"
note = """## Triage and analysis

### Investigating MFA Deactivation with no Re-Activation for Okta User Account

MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence.

This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours.

#### Possible investigation steps:

- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity.
- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target.
- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user.
- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.
    - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.
- Examine related administrative activity by the actor for privilege misuse or suspicious changes.

#### False positive steps:

- Determine with the target user if MFA deactivation was expected.
- Determine if MFA is required for the target user account.

#### Response and remediation:

- If the MFA deactivation was not expected, consider deactivating the user
    - This should be followed by resetting the user's password and re-enabling MFA.
- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives.
- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
- Check if the compromised account was used to access or alter any sensitive data, applications or systems.
- Review the client user-agent to determine if it's a known custom application that can be whitelisted.
"""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 21
rule_id = "cd89602e-9db0-48e3-9391-ae3bf241acd8"
setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
severity = "low"
tags = [
    "Tactic: Persistence",
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Domain: Cloud",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by okta.target.id with maxspan=12h
    [any where data_stream.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all")
        and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"]
    ![any where data_stream.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"]
'''


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

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

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

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

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

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

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

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

[rule]
description = """
Detects when an executable file is created by Curl, immediately made executable by Chmod and executed all within a 15
second timespan by the same parent process. This will detect attempts to gain initial access via shell scripts and
automated one line commands.
"""
id = "ab583372-b42e-4e5e-8e3a-fc900de0c34e"
license = "Elastic License v2"
name = "Payload Delivery via Curl and Immediate Execution"
os_list = ["macos"]
version = "1.0.6"

query = '''
sequence by process.parent.entity_id with maxspan=15s
[process where event.type == "start" and event.action == "exec" and process.name in ("curl", "nscurl") and
  process.args in ("-o", "--output") and
  not process.command_line : ("*https://raw.githubusercontent.com*", "*https://github.com*")]
[process where event.type == "start" and event.action == "exec" and process.name == "chmod" and process.args in ("+x", "777")]
[process where event.type == "start" and event.action == "exec" and (process.code_signature.trusted == false or process.code_signature.exists == false) and 
  not process.executable like ("/opt/homebrew/*", "/usr/local/Cellar/*")]
'''

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

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

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



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


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

[internal]
min_endpoint_version = "8.16.0"