Elastic rules: 10

[metadata]
creation_date = "2023/08/21"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2025/03/20"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies use of at.exe to interact with the task scheduler on remote hosts. Remote task creations, modifications or
execution could be indicative of adversary lateral movement.
"""
from = "now-119m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-system.security*",
    "logs-windows.*",
    "winlogbeat-*",
]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "At.exe Command Lateral Movement"
risk_score = 21
rule_id = "b483365c-98a8-40c0-92d8-0458ca25058a"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
    "Data Source: Elastic Endgame",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and process.name : "at.exe" and process.args : "\\\\*"
'''


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


[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 = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.002"
name = "At"
reference = "https://attack.mitre.org/techniques/T1053/002/"

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



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

[metadata]
creation_date = "2020/01/05"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/02/02"

[rule]
author = ["Elastic"]
description = "Identifies attempts to unload the Elastic Endpoint Security kernel extension via the kextunload command."
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Attempt to Unload Elastic Endpoint Security Kernel Extension"
risk_score = 73
rule_id = "70fa1af4-27fd-4f26-bd03-50b6af6b9e24"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and
 process.name == "kextunload" and process.args like~ ("*.EndpointSecurity", "/System/Library/Extensions/EndpointSecurity.kext", "EndpointSecurity.kext")
'''
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 Attempt to Unload Elastic Endpoint Security Kernel Extension

Elastic Endpoint Security's kernel extension is crucial for monitoring and protecting macOS systems by intercepting and analyzing system-level events. Adversaries may attempt to unload this extension using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events related to the `kextunload` command targeting the security extension, flagging potential defense evasion activities.

### Possible investigation steps

- Review the process event details to confirm the presence of the `kextunload` command targeting "EndpointSecurity.kext" in the process arguments.
- Identify the user account associated with the process event to determine if the action was initiated by an authorized or suspicious user.
- Check the host's recent activity logs for any other unusual or unauthorized actions that might indicate a broader attack or compromise.
- Investigate the source of the command execution by examining the parent process and any related processes to understand how the `kextunload` command was initiated.
- Assess the system for any signs of tampering or additional indicators of compromise, such as unauthorized file modifications or unexpected network connections.
- Correlate this event with other alerts or logs from the same host or user to identify potential patterns or coordinated activities.

### False positive analysis

- System administrators performing routine maintenance may trigger the rule when testing or updating kernel extensions. To manage this, create exceptions for known maintenance activities by whitelisting specific user accounts or processes during scheduled maintenance windows.
- Legitimate software updates or installations that require unloading the kernel extension might be flagged. To handle this, monitor and document regular update schedules and create exceptions for these activities, ensuring they align with expected update patterns.
- Security testing or audits conducted by authorized personnel could also trigger the rule. Implement a process to temporarily disable the rule or whitelist specific testing tools and accounts during these audits to prevent false positives.
- Development environments where kernel extensions are frequently loaded and unloaded for testing purposes may generate alerts. Consider setting up a separate monitoring profile for development systems with adjusted thresholds or exceptions to accommodate these activities.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or potential lateral movement by the adversary.
- Terminate any unauthorized processes related to the `kextunload` command to stop the attempt to unload the Elastic Endpoint Security kernel extension.
- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or indicators of compromise associated with the adversary's attempt.
- Restore the Elastic Endpoint Security kernel extension if it was successfully unloaded, ensuring that the system's protective measures are fully operational.
- Update and patch the macOS system and all security software to the latest versions to mitigate any known vulnerabilities that could be exploited by adversaries.
- Implement additional monitoring and alerting for any future attempts to execute the `kextunload` command, particularly targeting security-related kernel extensions.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational defenses need to be adjusted."""


[[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/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"



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

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to bypass Okta multi-factor authentication (MFA). An adversary may attempt to bypass the Okta MFA
policies configured for an organization in order to obtain unauthorized access to an application.
"""
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempted Bypass of Okta MFA"
note = """## Triage and analysis

### Investigating Attempted Bypass of Okta MFA

Multi-factor authentication (MFA) is a crucial security measure in preventing unauthorized access. Okta MFA, like other MFA solutions, requires the user to provide multiple means of identification at login. An adversary might attempt to bypass Okta MFA to gain unauthorized access to an application.

This rule detects attempts to bypass Okta MFA. It might indicate a serious attempt to compromise a user account within the organization's network.

#### Possible investigation steps

- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.
- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.
- Examine the `okta.outcome.reason` field for additional context around the bypass attempt.
- Check the `okta.outcome.result` field to confirm the MFA bypass attempt.
- Check if there are multiple unsuccessful MFA attempts from the same actor or IP address (`okta.client.ip`).
- Check for successful logins immediately following the MFA bypass attempt.
- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the bypass attempt.

### False positive analysis

- Check if there were issues with the MFA system at the time of the bypass attempt. This could indicate a system error rather than a genuine bypass attempt.
- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the login attempt. If these match the actor's normal behavior, it might be a false positive.
- Verify the actor's MFA settings to ensure they are correctly configured.

### Response and remediation

- If unauthorized access is confirmed, initiate the incident response process.
- Immediately lock the affected actor account and require a password change.
- Consider resetting MFA tokens for the actor and require re-enrollment.
- Check if the compromised account was used to access or alter any sensitive data or systems.
- If a specific MFA bypass technique was used, ensure your systems are patched or configured to prevent such techniques.
- Assess the criticality of affected services and servers.
- Work with your IT team to minimize the impact on users and maintain business continuity.
- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.
- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 73
rule_id = "3805c3dc-f82c-4f8d-891e-63c24d3102b0"
severity = "high"
tags = [
    "Data Source: Okta",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:user.mfa.attempt_bypass
'''


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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store
operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all
associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring
pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident
response.
"""
false_positives = [
    """
    CloudWatch log group deletions may occur during normal maintenance or infrastructure re-deployments, especially in
    environments managed by IaC tools (e.g., Terraform, CloudFormation, CDK). Automation pipelines may recreate log
    groups as part of expected workflows. Verify that the identity, user agent, and source IP match approved
    administrative or automation activity. If deletions are routine for specific automation roles or CI/CD hosts,
    consider adding scoped exceptions.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS CloudWatch Log Group Deletion"
note = """## Triage and analysis

### Investigating AWS CloudWatch Log Group Deletion

CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response.  
Log groups often contain retention-critical logs such as:

- VPC Flow Logs  
- Lambda function logs  
- Application and container logs  
- Security service logs (e.g., AWS WAF, RDS logs)

Deletion of a log group removes all historical log streams and cannot be reversed. 
Adversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non–AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines.

#### Possible investigation steps

 **Identify the actor**
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation.

**Review deletion details**
- Inspect `aws.cloudtrail.request_parameters` to determine the exact log group deleted.  
- Assess whether the log group provided visibility into:
  - CloudTrail processing,  
  - Network flows (VPC Flow Logs),  
  - Serverless/application security logs,  
  - Lambda, ECS, EKS, or container workload logs.

**Check source and context**
- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment.  
- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents).

**Correlate with surrounding activity**
Look for preceding or subsequent CloudTrail events such as:

- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes  
- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`)  
- Security service suppression actions (e.g., GuardDuty detector deletion)  
- Lambda or application configuration updates that may indicate a compromise  

If the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments.

**Assess business or security impact**
- Identify whether the deleted log group fed:
  - SIEM ingestion  
  - Security analytics pipelines  
  - Compliance/audit logs  
  - Operational monitoring or alerting  
- Contact the service owner or development team to verify whether the deletion was intentional.

**Determine compromise scope if malicious**
- Use CloudTrail to identify prior activity by the same user identity or IP.  
- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking.  
- Identify resources or applications dependent on the deleted logging pipeline.

### False positive analysis

- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments.  
- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows.  
- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups.

To tune noise:
- Add exceptions for specific automation IAM roles or trusted source IPs.
- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning.

### Response and remediation

**Containment**
- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console.  
- Restrict the IAM identity that performed the deletion until the activity is validated.  
- Enable or confirm CloudTrail logging in all regions to maintain broader visibility.

**Investigation**
- Review CloudTrail activity for:
  - privilege escalation attempts,  
  - IAM role modifications,  
  - security service tampering (CloudTrail, Config, GuardDuty).  
- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections).

**Recovery and hardening**
- Enforce least privilege on `logs:DeleteLogGroup`.  
- Configure AWS Config rules to alert on missing or modified log groups.  
- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion.  
- Document log group ownership and expected lifecycle management.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-group.html",
    "https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.html",
]
risk_score = 47
rule_id = "68a7a5a5-a2fc-4a76-ba9f-26849de881b4"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS CloudWatch",
    "Tactic: Defense Evasion",
    "Tactic: Impact",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" 
  and event.provider: "logs.amazonaws.com" 
  and event.action: "DeleteLogGroup" 
  and event.outcome: "success"
  and source.ip: * 
  and not user_agent.original : ("AWS Internal" or *Terraform* or *Pulumi*)
'''


[[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.technique.subtechnique]]
id = "T1562.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This
action could indicate an adversary attempting to maintain access to the instance. The rule detects the
SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key
to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2
Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or
AWS Management Console.
"""
false_positives = ["Administrators may upload SSH public keys to EC2 instances for legitimate purposes."]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Instance Connect SSH Public Key Uploaded"
note = """## Triage and Analysis

### Investigating AWS EC2 Instance Connect SSH Public Key Uploaded

This rule detects when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. Adversaries may upload SSH public keys to EC2 instances to maintain access to the instance or for initial access. This action also occurs automatically in the background when establishing a connection to an instance via the same service.  The rule covers cases where the `SendSerialConsoleSSHPublicKey` API action is used to upload an SSH public key to a serial connection, which can be exploited for privilege escalation.

#### Possible Investigation Steps:

- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.
- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the SSH public key upload. Look for any unusual parameters that could suggest unauthorized or malicious modifications. Determine the targeted EC2 instance.
- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the SSH public key was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.
- **Check for Serial Console Access**: If the `SendSerialConsoleSSHPublicKey` action was used, verify if the `ec2:EnableSerialConsoleAccess` permission was also used, which might indicate an attempt to enable and exploit the serial console.

### False Positive Analysis:

- **Legitimate Administrative Actions**: Confirm if the SSH public key upload aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.


### Response and Remediation:

- **Immediate Review and Reversal if Necessary**: If the upload was unauthorized, remove the uploaded SSH public key from the EC2 instance and review the instance's access logs for any suspicious activity.
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive instances or unusual file extensions.
- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning SSH key management and the risks of unauthorized key uploads.
- **Audit EC2 Instance Policies and Permissions**: Conduct a comprehensive audit of all EC2 instance policies and associated permissions to ensure they adhere to the principle of least privilege.
- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.

### Additional Information:

For further guidance on managing EC2 instances and securing AWS environments, refer to the [AWS EC2 Instance Connect documentation](https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html) and AWS best practices for security. Additionally, consult the following resources for specific details on SSH key management and privilege escalation techniques:
- [Stratus Red Team - AWS EC2 Instance Connect](https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/)
- [HackTricks - AWS EC2 Privilege Escalation](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc)
- [AWS EC2 Instance Connect API Reference](https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html)
"""
references = [
    "https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques",
    "https://medium.parttimepolymath.net/aws-ec2-instance-connect-a-very-neat-trick-4d2fc0c28010",
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc",
    "https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html",
    "https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSerialConsoleSSHPublicKey.html",
]
risk_score = 73
rule_id = "873b5452-074e-11ef-852e-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail
    and event.provider: ec2-instance-connect.amazonaws.com
    and event.action: (SendSSHPublicKey or SendSerialConsoleSSHPublicKey)
    and event.outcome: success
'''

[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 = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

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

[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 = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.004"
name = "SSH Authorized Keys"
reference = "https://attack.mitre.org/techniques/T1098/004/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.004"
name = "SSH Authorized Keys"
reference = "https://attack.mitre.org/techniques/T1098/004/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects the deletion of an Amazon GuardDuty threat intelligence set. Threat intelligence sets
are custom lists of known-malicious IP addresses or domains that GuardDuty uses to generate
findings when monitored resources communicate with those indicators. Deleting a threat intel set
degrades GuardDuty's detection capability for known adversary infrastructure, allowing
communication with threat-actor-controlled IP ranges to go undetected.
"""
false_positives = [
    """
    Removal of an outdated or inaccurate threat intelligence set during a scheduled feed
    rotation may trigger this rule. Confirm the deletion corresponds to a planned feed update
    and that a replacement set was activated.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS GuardDuty Threat Intelligence Set Deleted"
note = """## Triage and analysis

### Investigating AWS GuardDuty Threat Intelligence Set Deleted

GuardDuty threat intelligence sets allow security teams to upload custom lists of known-malicious IP addresses and domains. GuardDuty generates high-priority findings when monitored resources contact addresses in these sets. Deleting a threat intel set reduces GuardDuty's ability to detect communication with known adversary infrastructure.

Legitimate deletions occur during feed rotation (replacing an old set with an updated version) or when decommissioning a threat intel feed. Both operations should be planned and documented.

### Possible investigation steps

- Identify the caller from `aws.cloudtrail.user_identity.arn` and `user.name`.
- Check `aws.cloudtrail.request_parameters` for the threat intel set ID and detector ID. Determine whether any threat intel sets remain active in the detector.
- Review CloudTrail for adjacent GuardDuty control-plane modifications: `CreateThreatIntelSet`, `UpdateThreatIntelSet`, `CreateIPSet`, `UpdateIPSet`, `DeleteDetector`, `CreateFilter`.
- Determine whether a replacement threat intel set was created before or after the deletion.
- Correlate with other defense-evasion indicators such as GuardDuty detector updates or suppression rule creation.

### Response and remediation

- Re-create or restore the threat intelligence set if the deletion was unauthorized.
- Rotate credentials for the calling identity and review all actions taken by those credentials.
- Apply an SCP or IAM policy restricting `guardduty:DeleteThreatIntelSet` to a dedicated security operations role.
"""
references = [
    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteThreatIntelSet.html",
    "https://hackingthe.cloud/aws/avoiding-detection/modify-guardduty-config/",
]
risk_score = 47
rule_id = "7ba46fa6-496c-4d62-a811-7c221b3d2dd9"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. GuardDuty management events are logged by default."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS GuardDuty",
    "Rule Type: Custom Query (KQL)",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

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

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

[metadata]
creation_date = "2026/01/22"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the "curl" command-line tool with SOCKS proxy options. Attackers may use "curl" to establish a
SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers.
"""
false_positives = [
    """
    There is a potential for false positives if SOCKS proxies are used for legitimate purposes, such as debugging or
    troubleshooting, or if the "curl" command-line tool is used to download files from a known benign source. It is
    important to investigate any alerts generated by this rule to determine if they are indicative of malicious
    activity or part of legitimate container activity.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Curl SOCKS Proxy Detected via Defend for Containers"
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 SOCKS Proxy Detected via Defend for Containers

This detection flags curl invocations inside Linux containers that use SOCKS proxy options, indicating traffic tunneling to evade egress controls and enable data exfiltration or C2 communications. A common pattern is an operator with shell access launching curl -x socks5h://localhost:1080 or --socks5-hostname via a dynamically created SSH -D port, then fetching payloads, beaconing to external endpoints, or posting stolen data through the proxy.

### Possible investigation steps

- Retrieve the full curl command line to extract the SOCKS proxy host:port, target URLs, and signs of uploads or auth (e.g., -d/--data, -T/--upload-file, -H Authorization), then pivot those IOCs across container and cluster telemetry.
- If the proxy points to localhost or an internal address, confirm a SOCKS listener in the container or node network namespace and identify the owning process to reveal the tunneling mechanism.
- Examine the process ancestry and same TTY/session context to attribute the action and spot precursor activity such as ssh -D, chisel, cloudflared, tor, or 3proxy establishing the proxy.
- Correlate Kubernetes metadata (pod, namespace, service account, node, image) and kube-apiserver audit logs for exec/attach to identify the actor, verify legitimacy, and find similar events in sibling pods or earlier revisions.
- Review network flows and DNS from this container through the proxy to external destinations to quantify data volume and destination reputation, and check for access to sensitive internal services.

### False positive analysis

- A developer troubleshooting from an interactive shell inside a container runs curl with -x/--proxy socks5 options to validate egress or reach internal endpoints through an approved proxy (e.g., localhost or an internal host), generating a benign match.
- Shell profiles or container environment configuration automatically route curl through --preproxy/--socks5-hostname to access internal APIs or artifact mirrors during interactive checks, causing expected activity to be flagged.
"""
references = ["https://www.trendmicro.com/en_us/research/25/f/tor-enabled-docker-exploit.html"]
risk_score = 47
rule_id = "eb958cb3-dead-42b6-94ff-b9de6721fab2"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.name == "curl" and process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*", "-x") and
container.id like "?*"
'''

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

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

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

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

[metadata]
creation_date = "2026/05/26"
integration = ["entityanalytics_entra_id"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device
inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`.
This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build
typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue
devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic
access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline
approved device builds and naming conventions before relying on it.
"""
false_positives = [
    """
    Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default
    "DESKTOP-" host name. Validate against your device inventory and patch baseline before escalating.
    """,
    """
    Authorized red team or penetration testing engagements that use ROADtools to register devices will appear in the
    device inventory and match this rule. If this is expected, add exceptions for the specific host names or device IDs.
    """,
]
from = "now-6h"
index = ["logs-entityanalytics_entra_id.device-*"]
interval = "1h"
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Device with ROADtools Default OS Build (Entity Analytics)"
note = """## Triage and analysis

### Investigating Entra ID Device with ROADtools Default OS Build (Entity Analytics)

ROADtools (roadtx) registers a device in Entra ID with a default OS build of `10.0.19041.928` and a default name of
`DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and differs from
the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. This rule runs
against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint
appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event.
Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access
bypass, and persistent token-based access.

### Possible investigation steps

- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and
`entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention
are suspicious.
- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to
establish when and how the device was registered (e.g., Azure AD registered vs. joined).
- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine
whether that user is expected to register a new device.
- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; ROADtools
devices are typically unmanaged and non-compliant.
- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` event (initiated by the `Device Registration
Service`) and to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a
`primaryRefreshToken`.
- Correlate with the companion audit-log rule "Entra ID Device Registration with ROADtools Default OS Build"
for the same device name to confirm registration-time activity.

### False positive analysis

- Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default
`DESKTOP-` host name. Validate against device inventory and patch baseline.
- Authorized security assessments using ROADtools will appear in inventory. Document the engagement and add scoped
exceptions.

### Response and remediation

- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh
tokens.
- Disable the account or reset credentials per policy and review for additional persistence (added owners, app
registrations, or service principal credentials).
- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and
require MFA for registration).
"""
references = [
    "https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/",
    "https://github.com/dirkjanm/ROADtools",
    "https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/",
]
risk_score = 73
rule_id = "10b63b69-9f08-4767-b318-12208f97ad41"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Entity Analytics",
    "Use Case: Asset Visibility",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:"entityanalytics_entra_id.device" and
    event.provider:"Microsoft Entra ID" and
    host.name:DESKTOP-* and host.os.version:"10.0.19041.928"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "host.os.version",
    "event.provider",
    "entityanalytics_entra_id.device.display_name",
    "entityanalytics_entra_id.device.operating_system",
    "entityanalytics_entra_id.device.operating_system_version",
    "entityanalytics_entra_id.device.trust_type",
    "entityanalytics_entra_id.device.profile_type",
    "entityanalytics_entra_id.device.is_managed",
    "entityanalytics_entra_id.device.is_compliant",
    "entityanalytics_entra_id.device.registration_date_time",
    "entityanalytics_entra_id.device.registered_owners.user_principal_name",
    "entityanalytics_entra_id.device.id",
    "device.id",
]

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

[rule]
description = """
Identifies the execution of a file from a password protected self-extracting archive. Adversaries may encapsulate
malicious code in a protected archive to potentially bypass security controls.
"""
id = "559bb183-f343-4ad6-926f-144db38018d6"
license = "Elastic License v2"
name = "Execution from a Password Protected Self Extracting Archive"
os_list = ["windows"]
reference = [
    "https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/archive-sidestepping-self-unlocking-password-protected-rar/",
]
version = "1.0.22"

query = '''
sequence with maxspan=1m
  [file where event.action : "creation" and file.name : "*_sfx_access_check*"] by process.entity_id
  [process where event.action : "start" and
   process.parent.args : "-p*" and process.parent.args : "-d*"] by process.parent.entity_id
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[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/"

[internal]
min_endpoint_version = "7.15.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Detects a new private repo interaction for a GitHub PAT not seen in the last 14 days.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)"
risk_score = 21
rule_id = "1e9b271c-8caa-4e20-aed8-e91e34de9283"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Execution",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset:"github.audit" and event.category:"configuration" and
github.repo:* and github.hashed_token:* 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 = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.new_terms]
field = "new_terms_fields"
value = ["github.hashed_token", "github.repo"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2025/12/16"
integration = ["github"]
maturity = "production"
updated_date = "2026/05/12"

[rule]
author = ["Elastic"]
description = """
Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository
visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or
unauthorized access.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Private Repository Turned Public"
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 GitHub Private Repository Turned Public

This rule flags when a previously private repository is made public, a high-risk change that can expose proprietary code, credentials, and internal documentation. Attackers who hijack a maintainer’s account often flip visibility via the UI or API, then immediately fork or mirror the repo to an external account to retain access and harvest embedded secrets even if the org reverts the change.

### Possible investigation steps

- Identify the actor and authentication method used for the visibility change, verify their repository role, and confirm the action against an approved change request or ticket.
- Pull a time-bounded audit trail around the event for the actor and repository to surface related risky operations such as forking, transfers, collaborator additions, webhook edits, branch protection changes, or archive downloads.
- Enumerate forks, mirrors, stars, and watchers added after the change via the repository network graph and correlate with external accounts or suspicious clusters.
- Inspect GitHub Actions runs, deployments, and webhooks triggered post-change for workflows that export code or secrets to external destinations.
- Perform rapid secret scanning across the repository history and HEAD, triage any exposed credentials, and initiate rotation while mapping impacted services and environments.

### False positive analysis

- A planned, approved open-source release where a maintainer intentionally flips a sanitized repository from private to public as part of a documented change.
- Bulk visibility changes during an organization-wide cleanup or migration that publishes templates, sample repos, or empty scaffolds, executed by an authorized service account.

### Response and remediation

- Immediately revert the repository to private, remove outside collaborators, lock access to the core maintainers team, disable GitHub Actions and webhooks, and delete any release assets or packages published during the exposure window.
- Enumerate new forks, mirrors, stars, and watchers created after the visibility change and file takedown requests with GitHub Trust & Safety for unauthorized public copies while removing any deploy keys and uninstalling suspicious GitHub App installations added around the event.
- Run a rapid secret scan across the repository history and HEAD, rotate exposed credentials (cloud keys, API tokens, SSH keys), invalidate compromised service accounts, and purge cached artifacts or container images built from the public commit range.
- Restore secure settings from baseline by re-applying branch protection rules, CODEOWNERS, required reviews, signed commits, and protected environments, then re-enable workflows only after reviewing job steps and outputs for any export of code or secrets.
- Escalate to Security IR and Legal if the actor denies making the change, the repo network graph shows new public forks under unknown accounts, regulated data is present, or external users downloaded source zips or release archives during the public period.
- Restrict who can change repository visibility to organization owners, enforce SSO and 2FA for maintainers, disable forking of private repositories, limit Actions to trusted runners and verified actions, and enable secret scanning with push protection across the organization.
"""
risk_score = 21
rule_id = "8c707e4c-bd20-4ff4-bda5-4dc3b34ce298"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Tactic: Impact",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
configuration where data_stream.dataset == "github.audit" and github.operation_type == "modify" and github.category == "repo" and
event.action == "repo.access" and github.visibility == "public"
'''

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

[[rule.threat.technique]]
id = "T1020"
name = "Automated Exfiltration"
reference = "https://attack.mitre.org/techniques/T1020/"

[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

[[rule.threat.technique.subtechnique]]
id = "T1567.001"
name = "Exfiltration to Code Repository"
reference = "https://attack.mitre.org/techniques/T1567/001/"

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

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

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

[rule]
description = """
Identifies attempt to perform code injection via image hollowing replacing image mapped memory content with malicious
one.
"""
id = "c6231a7f-edb0-455f-9bc0-5a1b0213bb29"
license = "Elastic License v2"
name = "Hollow Image Behavior via Native API"
os_list = ["windows"]
version = "1.0.4"

query = '''
api where process.Ext.api.name == "VirtualProtect" and process.Ext.api.behaviors == "hollow_image" and
  process.Ext.api.behaviors == "native_api" and
  process.thread.Ext.call_stack_final_user_module.hash.sha256 like "?*" and
  not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true) and
  /* ntdll and kernel32 covered in other rules */
  not process.Ext.api.metadata.target_address_name in ("ntdll.dll", "kernel32.dll", "Unknown") and
  not process.thread.Ext.call_stack_final_user_module.path :
                                       ("?:\\windows\\assembly\\nativeimages_*",
                                        "?:\\windows\\installer\\*.tmp",
                                        "c:\\windows\\system32\\dk?win64.dll",
                                        "c:\\windows\\system32\\ntdll.dll",
                                        "c:\\windows\\system32\\lsasrv.dll",
                                        "c:\\windows\\system32\\cpsrt.dll",
                                        "c:\\program files\\*",
                                        "c:\\program files (x86)\\*") and
  not (process.Ext.api.metadata.target_address_name == "clr.dll" and process.Ext.api.parameters.size == 428) and
  not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info : "c:\\windows\\sys?????\\ntdll.dll!LdrResolveDelayLoadsFromDll*") and
  not (process.thread.Ext.call_stack_final_user_module.path : "c:\\windows\\system32\\spool\\drivers\\x64\\3\\*.dll" and process.Ext.api.parameters.size <= 4096) and
  not process.thread.Ext.call_stack_final_user_module.hash.sha256 in ("aac0a89af89d77fa1af4a9a97657f4dfb83b97b73ec02502fe72b72c835abe31",
                                                                      "2c20ff3a1c0da227e018d40c15c35a7c27179b3e19be9cd2a6bd9b8770a2d5b3",
                                                                      "7fc60aa75973dae70d84d2d9e5b4222716e316f00374efad8927da584cec813a",
                                                                      "0e103cdf3dfa0416e7cb71940ab2a3f53127e7843e86a2e4621d3a21915c1ff7",
                                                                      "f6686978245410dffddc66015bce1baea96c1c3ed0f9d4c9f476e4cf8cb75afb",
                                                                      "9354d9bdbc7f0779a1a8693296171e13cbe6714c15c9c0f934c67e499fbcdff0",
                                                                      "4772629a7e2380d28e33fdace1d309d805f6c9973fecc3bb7fe6dc1553d137f1",
                                                                      "012773a05c29d8d779b7f529ed4e2919b5c2af260acd5a2bd0fb5efafbf435e1",
                                                                      "64d5ccfb2a51525f66cb00aeb7959abe68024c7cece2c82192aff44300e944f3",
                                                                      "d38de4cdb43df6e9992fb88c477ba1bbca4d43aba8c4296626eac2919a81c697",
                                                                      "2771c5b49d89aff611033d2025b9e0690226a7654d6a5cfc0420b18d8965cc67")
'''

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

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

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



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

[internal]
min_endpoint_version = "8.10.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies InstallUtil.exe making outbound network connections. This may indicate adversarial activity as InstallUtil is
often leveraged by adversaries to execute code and evade detection.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "winlogbeat-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "InstallUtil Process Making Network Connections"
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 InstallUtil Process Making Network Connections

InstallUtil.exe is a legitimate Windows utility used for installing and uninstalling server resources by executing installer components. Adversaries exploit it to run malicious code under the guise of legitimate processes, often to evade detection. The detection rule identifies suspicious network activity by monitoring InstallUtil.exe's outbound connections, flagging potential misuse by alerting on the initial network connection attempt.

### Possible investigation steps

- Review the alert details to confirm the process.entity_id and ensure it matches the InstallUtil.exe process making the outbound network connection.
- Investigate the destination IP address and port of the network connection to determine if it is known, trusted, or associated with malicious activity.
- Examine the parent process of InstallUtil.exe to identify how it was launched and assess if this behavior is expected or potentially malicious.
- Check the timeline of events around the process start and network connection to identify any other suspicious activities or related processes.
- Look for any additional network connections made by the same process.entity_id to assess if there is a pattern or further evidence of malicious behavior.
- Review system logs and security alerts for any other indicators of compromise or related suspicious activities on the host.

### False positive analysis

- Legitimate software installations or updates may trigger InstallUtil.exe to make network connections. Users can create exceptions for known software update processes by identifying their specific process entity IDs and excluding them from the alert.
- System administrators may use InstallUtil.exe for routine maintenance tasks that require network access. To prevent false positives, document these tasks and configure the detection rule to exclude these specific instances.
- Automated deployment tools that utilize InstallUtil.exe for legitimate purposes can be a source of false positives. Identify these tools and their associated network activities, then adjust the rule to ignore these benign connections.
- Development environments where InstallUtil.exe is used for testing purposes might generate alerts. Establish a list of development machines and exclude their process entity IDs from the detection rule to reduce noise.
- Scheduled tasks or scripts that use InstallUtil.exe for legitimate network operations should be reviewed. Once verified as non-threatening, these can be added to an exception list to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
- Terminate the InstallUtil.exe process on the affected system to stop any ongoing malicious actions.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or associated files.
- Review and analyze the network logs to identify any other systems that may have been contacted by the malicious process and assess if they are compromised.
- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
- 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 network monitoring and alerting for unusual outbound connections from critical systems to enhance detection of similar threats in the future."""
risk_score = 47
rule_id = "a13167f1-eec2-4015-9631-1fee60406dcf"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
    "Data Source: SentinelOne",
]
type = "eql"

query = '''
/* the benefit of doing this as an eql sequence vs kql is this will limit to alerting only on the first network connection */

sequence by process.entity_id
  [process where host.os.type == "windows" and event.type == "start" and process.name : "installutil.exe"]
  [network where host.os.type == "windows" and process.name : "installutil.exe" and network.direction : ("outgoing", "egress")]
'''

setup = """## Setup

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

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

### Additional data sources

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

- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""


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



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

[rule]
description = """
Detects unsigned binaries masquerading as "Ledger Live" cryptocurrency wallet software. These fake applications steal
wallet seed phrases and private keys from victims through social engineering.
"""
id = "49c1f843-2461-4714-bdb1-ec8f0d930afb"
license = "Elastic License v2"
name = "Malicious Ledger Live Execution"
os_list = ["macos"]
reference = ["https://x.com/moonlock_lab/status/1902381331490738345"]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and process.name like~ "ledger live" and 
 process.code_signature.trusted == false
'''

min_endpoint_version = "8.11.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 = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[threat.technique.subtechnique]]
id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"



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

[internal]
min_endpoint_version = "8.11.0"

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

[rule]
author = ["Elastic"]
description = """
Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can
abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials
contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys,
certificates, and certificate requests.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "Modification of the msPKIAccountCredentials"
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 Modification of the msPKIAccountCredentials

The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts.

### Possible investigation steps

- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved.
- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18).
- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies.
- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute.
- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials.
- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack.

### False positive analysis

- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly.
- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule.
- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows.
- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts.
- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse.
- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns.
- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities.
- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials."""
references = [
    "https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming",
    "https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx",
    "https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136",
]
risk_score = 47
rule_id = "670b3b5a-35e5-42db-bd36-6c5b9b4b7313"
setup = """## Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-changes
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Data Source: Active Directory",
    "Tactic: Privilege Escalation",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and
  winlog.event_data.OperationType:"%%14674" and
  not winlog.event_data.SubjectUserSid : "S-1-5-18"
'''


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

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

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

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

[rule]
description = """
Identifies registry modification activity consistent with the NetWire Remote Access Trojan (RAT). NetWire is a publicly
available, multi-platform RAT that is used by criminal and APT groups.
"""
id = "102f340f-1839-4bad-8493-824cc02c4e69"
license = "Elastic License v2"
name = "NetWire RAT Registry Modification"
os_list = ["windows"]
reference = [
    "https://any.run/malware-trends/netwire",
    "https://attack.mitre.org/software/S0198/",
    "https://www.elastic.co/security-labs/exploring-the-ref2731-intrusion-set",
]
version = "1.0.30"

query = '''
registry where
   registry.path : (
      "HKEY_USERS\\S-1-5-21-*\\SOFTWARE\\NetWire\\HostId",
      "HKEY_USERS\\S-1-5-21-*\\SOFTWARE\\NetWire\\Install Date",
      "HKEY_USERS\\S-1-12-1-*\\SOFTWARE\\NetWire\\HostId",
      "HKEY_USERS\\S-1-12-1-*\\SOFTWARE\\NetWire\\Install Date"
      )
'''

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

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

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


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

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

[internal]
min_endpoint_version = "7.15.0"

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

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

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

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

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


[rule]
author = ["Elastic"]
description = """
Binaries signed with trusted digital certificates can execute on Windows systems protected by digital signature
validation. Adversaries may use these binaries to 'live off the land' and execute malicious files that could bypass
application allowlists and signature validation.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Network Connection via Signed Binary"
note = """## Triage and analysis

### Investigating Network Connection via Signed Binary

By examining the specific traits of Windows binaries (such as process trees, command lines, network connections, registry modifications, and so on) it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation.

This rule looks for the execution of `expand.exe`, `extrac32.exe`, `ieexec.exe`, or `makecab.exe` utilities, followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities to bypass detections and evade defenses.

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

#### Possible investigation steps

- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
  - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
  - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware.
- Investigate the target host that the signed binary is communicating with.
  - Check if the domain is newly registered or unexpected.
  - Check the reputation of the domain or IP address.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Analyze the process executable using a private sandboxed analysis system.
  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

### False positive analysis

- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of destination IP address and command line conditions.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

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

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

### Additional data sources

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

- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""

references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
risk_score = 21
rule_id = "63e65ec3-43b1-45b0-8f2d-45b34291dc44"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Sysmon",
]
type = "eql"

query = '''
sequence by process.entity_id
  [process where host.os.type == "windows" and (process.name : "expand.exe" or process.name : "extrac32.exe" or
                 process.name : "ieexec.exe" or process.name : "makecab.exe") and
                 event.type == "start"]
  [network where host.os.type == "windows" and (process.name : "expand.exe" or process.name : "extrac32.exe" or
                 process.name : "ieexec.exe" or process.name : "makecab.exe") and
    not cidrmatch(destination.ip,
      "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32",
      "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24",
      "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24",
      "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")]
'''


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


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

[metadata]
creation_date = "2024/01/10"
integration = ["endpoint"]
maturity = "production"
updated_date = "2024/12/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the ability of a process to be able to create RAW and PACKET socket types for the available network
namespaces by a non-root user. A malicious process with this capability may exploit routing between hosts, bypass
network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet
types and contents. The CAP_NET_RAW capability allows the process to bind to any address within the available
namespaces, which allows network traffic sniffing by a non root user. The rule identifies previously unknown processes
executing with CAP_NET_RAW capabilities through the use of the new terms rule type.
"""
from = "now-119m"
index = ["logs-endpoint.events.*"]
interval = "60m"
language = "kuery"
license = "Elastic License v2"
name = "Network Traffic Capture via CAP_NET_RAW"
risk_score = 21
rule_id = "e28b8093-833b-4eda-b877-0873d134cf3c"
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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.category:"process" and host.os.type:"linux" and event.type:"start" and event.action:"exec" and process.name:* and
(process.thread.capabilities.effective:"CAP_NET_RAW" or process.thread.capabilities.permitted:"CAP_NET_RAW") and
not user.id:"0"
'''

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

[[rule.threat.technique]]
id = "T1040"
name = "Network Sniffing"
reference = "https://attack.mitre.org/techniques/T1040/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["process.executable"]

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

[metadata]
creation_date = "2024/03/06"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the creation of Pluggable Authentication Module (PAM) shared object files or configuration
files. Attackers may create these files to maintain persistence on a compromised system, or harvest account credentials.
"""
false_positives = [
    "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes.",
]
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Pluggable Authentication Module or Configuration Creation"
note = """## Triage and analysis

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

### Investigating Pluggable Authentication Module or Configuration Creation

Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating or altering its modules or configurations to gain persistence or capture credentials. The detection rule identifies suspicious activities by monitoring file operations in PAM directories, excluding legitimate processes, thus highlighting potential unauthorized modifications.

### Possible investigation steps

- Review the file path and extension to determine if the modified or created file is a PAM shared object or configuration file, focusing on paths like "/lib/security/*", "/etc/pam.d/*", and "/etc/security/pam_*".
- Identify the process executable responsible for the file operation and verify if it is listed as an excluded legitimate process, such as "/bin/dpkg" or "/usr/bin/yum". If not, investigate the process further.
- Check the process execution history and command line arguments to understand the context of the file operation and assess if it aligns with typical system administration tasks.
- Investigate the user account associated with the process to determine if it has legitimate access and permissions to modify PAM files, and check for any signs of compromise or misuse.
- Examine recent system logs and security alerts for any related suspicious activities or anomalies that might indicate a broader attack or compromise.
- If the file operation is deemed suspicious, consider restoring the original PAM configuration from a known good backup and monitor the system for any further unauthorized changes.

### False positive analysis

- Package management operations: Legitimate package managers like dpkg, rpm, and yum may trigger the rule during software updates or installations. To handle this, exclude these processes by adding them to the exception list in the rule configuration.
- System updates and maintenance: Processes such as pam-auth-update and systemd may modify PAM configurations during routine system updates. Exclude these processes to prevent false positives.
- Temporary files: Files with extensions like swp, swpx, and swx are often temporary and not indicative of malicious activity. Exclude these extensions to reduce noise.
- Development environments: Paths like /nix/store/* and /snap/* may be used in development or containerized environments. Consider excluding these paths if they are part of a known and secure setup.
- Automated scripts: Scripts using tools like sed or perl may create temporary files that match the rule's criteria. Exclude these specific patterns if they are part of regular, non-malicious operations.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Review the specific PAM module or configuration file that was created or modified to understand the changes made and assess the potential impact on system security.
- Restore the affected PAM files from a known good backup to ensure the integrity of the authentication process and remove any malicious modifications.
- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious software that may have been introduced.
- Monitor the system and network for any signs of continued unauthorized access or suspicious activity, focusing on the indicators of compromise related to PAM manipulation.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
- Implement additional monitoring and alerting for PAM-related activities to enhance detection capabilities and prevent similar threats in the future."""
references = [
    "https://github.com/zephrax/linux-pam-backdoor",
    "https://github.com/eurialo/pambd",
    "http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html",
    "https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html",
]
risk_score = 47
rule_id = "f48ecc44-7d02-437d-9562-b838d2c41987"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action == "creation" and process.executable != null and (
  (file.path like (
    "/lib/security/*", "/lib64/security/*", "/usr/lib/security/*", "/usr/lib64/security/*",
    "/lib/x86_64-linux-gnu/security/*", "/usr/lib/x86_64-linux-gnu/security/*"
  ) and file.extension == "so") or
  (file.path like "/etc/pam.d/*" and file.extension == null) or
  (file.path like "/etc/security/pam_*" or file.path == "/etc/pam.conf")
) and not (
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/sbin/pam-auth-update",
    "/usr/lib/systemd/systemd", "/usr/libexec/packagekitd", "/usr/bin/bsdtar", "/sbin/pam-auth-update", "./user/bin/podman",
    "/usr/bin/dnf5", "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/crio", "/sbin/authconfig", "/usr/sbin/yum-cron",
    "/sbin/yum-cron", "/usr/local/psa/bin/dnf_install", "/opt/jc/bin/jumpcloud-agent", "./usr/bin/podman",
    "/kaniko/executor", "/opt/kaniko/executor", "/usr/bin/buildah", "/usr/sbin/pam-config",
    "./usr/lib/snapd/snap-update-ns", "/usr/bin/install", "/usr/bin/env"
  ) or
  file.path like (
    "/tmp/snap.rootfs_*/pam_*.so", "/tmp/newroot/lib/*/pam_*.so", "/tmp/newroot/usr/lib64/security/pam_*.so"
  ) or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  file.Ext.original.extension == "dpkg-new" or
  file.Ext.original.name like "*.pam-new" or
  process.executable like (
    "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/usr/bin/python*",
    "/opt/alt/python*/bin/python*", "/usr/libexec/platform-python*", "./snap/snapd/*/usr/lib/snapd/snap-update-ns"
  ) or
  (process.name == "sed" and file.name like~ "sed*") or
  (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") or
  (process.name == "perl" and event.action == "rename" and file.Ext.original.name like "*.pam-new") or
  process.name like ("python*", "platform-python*", "dockerd") or
  (process.name == "vim.basic" and file.name like "*~")
)
'''

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.003"
name = "Pluggable Authentication Modules"
reference = "https://attack.mitre.org/techniques/T1556/003/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.003"
name = "Pluggable Authentication Modules"
reference = "https://attack.mitre.org/techniques/T1556/003/"

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