deardaniel/secdata-raw huggingface dataset:
Elastic SIEM Detection Rules: aws bedrock ignore previous prompt detection

# AWS Bedrock LLM Ignore Previous Prompt Detection

---

## Metadata

- **Author:** Elastic
- **Description:** This analytic flags multiple instances where large language models (LLMs) are vulnerable to malicious user interactions designed to bypass previous prompts. This can lead to the generation of inappropriate or harmful content, resulting in direct LLM prompt injection.
- **UUID:** `131e5887-463a-46a1-a44e-b96361bc6cbc`
- **Integration:** [aws_bedrock.invocation](https://docs.elastic.co/integrations/aws_bedrock)
- **Language:** `[ES|QL]`
- **Source File:** [AWS Bedrock LLM Ignore Previous Prompt Detection](../queries/aws_bedrock_ignore_previous_prompt_detection.toml)

## Query

```sql
from logs-aws_bedrock.invocation-*
 |EVAL lowercase_prompt = TO_LOWER(gen_ai.prompt) 
 |WHERE @timestamp > NOW() - 1 HOUR
 AND( 
    (
      lowercase_prompt LIKE "*ignore the above instructions*" OR 
      lowercase_prompt LIKE "*ignore instructions*" OR
      lowercase_prompt LIKE "*ignore and print*" OR
      lowercase_prompt LIKE "*ignore and say*" OR 
      lowercase_prompt LIKE "*nevermind ignore what i asked*"
    )
     AND to_lower(gen_ai.completion) LIKE "*end_turn*"
   )
 | STATS user_request_count = count(*) BY gen_ai.user.id
 | WHERE user_request_count >= 2
```

## Notes

- Examine flagged interactions for patterns or anomalies in user requests that may indicate malicious intent to expose LLM vulnerabilities
- Regularly review and update the phrases that trigger ignore previous prompt attacks to adapt to new ethical guidelines and compliance requirements.
- Ensure that data logs contain enough detail to provide context around the refusal, which will aid in subsequent investigations by security teams.

## MITRE ATT&CK Techniques

- [AML.T0051.000](https://atlas.mitre.org/techniques/AML.T0051.000)

## References

- https://www.elastic.co/security-labs/elastic-advances-llm-security
- https://github.com/agencyenterprise/PromptInject?tab=readme-ov-file

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: iam user activity with no mfa session

# IAM User Activity with No MFA Session

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query gathers data for evidence of an IAM user activity with no MFA session. This query identifies IAM user activity where the user is not MFA authenticated. Adversaries often target IAM users with weak or no MFA protection to gain unauthorized access to AWS resources after compromising the user's credentials via phishing, third-party breaches, or brute-forcing.

- **UUID:** `913a47be-649c-11ef-a693-f661ea17fbcc`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [IAM User Activity with No MFA Session](../queries/iam_user_activity_with_no_mfa_session.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where event.dataset == "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type == "IAMUser"
    and aws.cloudtrail.user_identity.session_context.mfa_authenticated == "false"
    and not user_agent.original in ("cloudformation.amazonaws.com", "application-autoscaling.amazonaws.com", "AWS Internal")
    and (aws.cloudtrail.user_identity.access_key_id is null or aws.cloudtrail.user_identity.access_key_id == "")
| stats activity_counts = count(*) by event.provider, event.action, aws.cloudtrail.user_identity.arn
```

## Notes

- Review the `user_identity.arn` field to identify if activity is sourcing from a browser or programmatically via the AWS CLI or SDK.
- Review aggregated counts of API calls made for suspicious discovery or reconnaissance such as `List*`, `Describe*`, or `Get*` API calls.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: s3 public bucket rapid object access attempts

# S3 Public Bucket Rapid Object Access Attempts

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when an anonymous user, outside of the known AWS IP ranges, makes multiple `GetObject` requests to a public S3 bucket. Rapid access to objects in a public S3 bucket may indicate an adversary attempting to exfiltrate data or perform reconnaissance on the bucket contents.

- **UUID:** `ef579900-75ef-11ef-b47f-f661ea17fbcc`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [S3 Public Bucket Rapid Object Access Attempts](../queries/s3_public_bucket_rapid_object_access_attempts.toml)

## Query

```sql
from logs-aws.cloudtrail*
| where @timestamp > now() - 7 day
| where event.provider == "s3.amazonaws.com" and event.action == "GetObject" and cloud.account.id == "anonymous"
    and NOT CIDR_MATCH(source.ip,
       "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16",
       "100.64.0.0/10", "169.254.0.0/16", "127.0.0.0/8",
       "52.95.0.0/16","54.239.0.0/16", "18.0.0.0/8",
       "3.0.0.0/8", "35.0.0.0/8")
| DISSECT aws.cloudtrail.request_parameters "{%{?bucket_name_key}=%{bucket_name}, %{?host_key}=%{bucket_location}, %{?object_key}=%{bucket_object}}"
| STATS s3_bucket_access_count = COUNT(bucket_object) by bucket_name
| WHERE s3_bucket_access_count >= 15
```

## Notes

- Use the `bucket_name` field to identify the public S3 bucket that the objects were accessed from
- Use the `bucket_object` field to identify the objects that were accessed
- Review bucket policies and access control lists (ACLs) to ensure that the bucket is not publicly accessible
- 

## MITRE ATT&CK Techniques

- [T1530](https://attack.mitre.org/techniques/T1530)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: signin single factor console login via federated session

# Signin Single Factor Console Login via Federated Session

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a user signs in to the AWS Management Console using a federated session and single-factor authentication. Federated sessions are typically used by users who are not directly managed by AWS IAM or have temporary credentials. Single-factor authentication without MFA may indicate a security risk, as MFA adds an additional layer of security to the authentication process. This could also indicate the abuse of STS tokens to bypass MFA requirements.

- **UUID:** `953b1252-5efd-11ef-a997-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [Signin Single Factor Console Login via Federated Session](../queries/signin_single_factor_console_login_via_federated_session.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where
    event.provider == "signin.amazonaws.com"
    and event.action == "GetSigninToken"
    and aws.cloudtrail.event_type == "AwsConsoleSignIn"
    and aws.cloudtrail.user_identity.type == "FederatedUser"
| dissect aws.cloudtrail.additional_eventdata "{%{?mobile_version_key}=%{mobile_version}, %{?mfa_used_key}=%{mfa_used}}"
| where mfa_used == "No"
| keep @timestamp, event.provider, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type, aws.cloudtrail.additional_eventdata, mobile_version, mfa_used
```

## Notes

- Use the `aws.cloudtrail.user_identity.type` field to identify the user type making the request. Federated users are typically given temporary credentials to access AWS services.
- `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field represents the ARN of the IAM entity that created the federated session. This IAM entity could be compromised and used to create federated sessions.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: lambda add permissions for write actions to function

# Lambda Add Permissions for Write Actions to Function

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query gathers data for evidence of an adversary adding permissions to a Lambda function that allows write actions. The `AddPermission` API call to Lambda allows the adversary to add permissions to a Lambda function. This query identifies when the `AddPermission` API call is used to add permissions that allow write actions to a Lambda function. Adversaries may use this technique to grant themselves additional permissions to write to a Lambda function, which could be used to execute malicious code or exfiltrate data.

- **UUID:** `e3206d1c-64a9-11ef-a642-f661ea17fbcc`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [Lambda Add Permissions for Write Actions to Function](../queries/lambda_add_permissions_for_write_actions_to_function.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where
    event.dataset == "aws.cloudtrail"
    and event.provider == "lambda.amazonaws.com"
    and event.action RLIKE "AddPermission.*"
| dissect aws.cloudtrail.request_parameters "{%{?principal_key}=%{principal_id}, %{?function_name_key}=%{function_name}, %{?statement_key}=%{statement_value}, %{?action_key}=lambda:%{action_value}}"
| eval write_action = (starts_with(action_value, "Invoke") or starts_with("Update", action_value) or starts_with("Put", action_value))
| where write_action == true
| keep @timestamp, principal_id, event.provider, event.action, aws.cloudtrail.request_parameters, principal_id, function_name, action_value, statement_value, write_action
```

## Notes

- Analyze the `principal_id` to identify the entity that the permission is being granted to. Adversaries may use this technique to grant themselves additional permissions.
- Review the `function_name` to identify the Lambda function that the permission is being added to.
- Identify the `action_value` to determine the type of action that the permission allows. Write actions may include `Invoke`, `Update`, or `Put`.
- 

## MITRE ATT&CK Techniques

- [T1584.007](https://attack.mitre.org/techniques/T1584/007)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: servicequotas discovery multi region get service quota calls

# High Frequency of Service Quotas Multi-Region `GetServiceQuota` API Calls

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance.

- **UUID:** `7a083b24-6482-11ef-8a8f-f661ea17fbcc`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [High Frequency of Service Quotas Multi-Region `GetServiceQuota` API Calls](../queries/servicequotas_discovery_multi_region_get_service_quota_calls.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day

// filter for GetServiceQuota API calls
| where event.dataset == "aws.cloudtrail" and event.provider = "servicequotas.amazonaws.com" and event.action == "GetServiceQuota"

// truncate the timestamp to a 30-second window
| eval target_time_window = DATE_TRUNC(30 seconds, @timestamp)

// pre-process the request parameters to extract the service code and quota code
| dissect aws.cloudtrail.request_parameters "{%{?service_code_key}=%{service_code}, %{?quota_code_key}=%{quota_code}}"

// filter for EC2 service quota L-1216C47A (vCPU on-demand instances)
| where service_code == "ec2" and quota_code == "L-1216C47A"

// count the number of unique regions and total API calls within the 30-second window
| stats region_count = count_distinct(cloud.region), window_count = count(*) by target_time_window, aws.cloudtrail.user_identity.arn

// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window
| where region_count >= 10 and window_count >= 10

// sort the results by time windows in descending order
| sort target_time_window desc
```

## Notes

- Use the `aws.cloudtrail.user_identity.arn` field to identify the user making the requests and their role permissions
- Use the `cloud.region` field to identify the regions where the `GetServiceQuota` API calls were made
- Review Elastic Defend alerts for endpoint related activity to identify potential malware or cryptocurrency mining activity
- If a valid account compromise is suspected, review source.* fields for the IP address and geographical location of the request and compare with the user's typical behavior
- Query for `RunInstances` API calls to determine if new instances were launched using the on-demand instances
- If new instances were launched, review the instance metadata and user data scripts for malicious content

## MITRE ATT&CK Techniques

- [T1580](https://attack.mitre.org/techniques/T1580)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: ssm sendcommand api used by ec2 instance

# SSM SendCommand API Used by EC2 Instance

---

## Metadata

- **Author:** Elastic
- **Description:** An attacker with compromised EC2 instance credentials, may use those credentials to attempt remote code execution against the EC2 instance from which the credentials were compromised via SSM SendCommand API.

- **UUID:** `38454a64-5b55-11ef-b345-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [SSM SendCommand API Used by EC2 Instance](../queries/ssm_sendcommand_api_used_by_ec2_instance.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where event.dataset == "aws.cloudtrail"
    and event.provider == "ssm.amazonaws.com"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and event.action == "SendCommand"
    and user.id like "*:i-*"
| keep @timestamp, event.provider, event.action, aws.cloudtrail.user_identity.type, user.id, aws.cloudtrail.request_parameters
```

## Notes

- The indicator that this is an EC2 instance assuming a role and performing the action, is the use of the instance id beginning with -i as the session name.
- Session name is attached to the end of the `user.id` field and the `aws.cloudtrail.user_identity.arn`.

## MITRE ATT&CK Techniques

- [T1651](https://attack.mitre.org/techniques/T1651)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: multiple service logging deleted or stopped

# Multiple Service Logging Deleted or Stopped

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies the deletion or stopping of multiple service logging actions within AWS. Service logging is a critical security control that provides visibility into the activities and changes within AWS services. Adversaries may attempt to disable or delete service logging to evade detection and cover their tracks. Monitoring for multiple service logging deletions or stops can help identify potential malicious activity and ensure that critical security controls remain intact.

- **UUID:** `d74f8928-5e46-11ef-9488-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [Multiple Service Logging Deleted or Stopped](../queries/multiple_service_logging_deleted_or_stopped.toml)

## Query

```sql
from logs-aws.cloudtrail*
| where @timestamp > now() - 7 day
| where
    event.provider in ("ec2.amazonaws.com","route53resolver.amazonaws.com","s3.amazonaws.com", "cloudtrail.amazonaws.com")
    and event.action in ("DeleteFlowLogs","DeleteResolverQueryLogConfig", "DeleteTrail", "StopLogging")
| eval date = DATE_FORMAT("YYYY-mm-dd", @timestamp)
| stats service_logging_delete_count = count(*) by event.provider, event.action, event.outcome, date, aws.cloudtrail.user_identity.arn
```

## Notes

- Use the `event.provider` field to identify the service logging action that was deleted or stopped
- Use the `event.action` field to identify the specific action that was taken on the service logging
- Review the `aws.cloudtrail.user_identity*` fields to identify the user making the requests and their role permissions
- Review the `source.*` fields for the IP address and geographical location of the request and compare with the user's typical behavior
- Check for `CreateFlowLogs`, `CreateResolverQueryLogConfig`, `CreateTrail`, and `StartLogging` API calls to determine if the service logging was recently enabled or started. This could help determine if the deletion was due to maintence or configuration changes
- Use ES|QL `stats` function to aggregated on date to identify patterns of multiple service logging deletions or stops
- 

## MITRE ATT&CK Techniques

- [T1562.008](https://attack.mitre.org/techniques/T1562/008)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: ssm start remote session to ec2 instance

# SSM Start Remote Session to EC2 Instance

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a user starts a remote session to an EC2 instance using the AWS Systems Manager (SSM) service. The `StartSession` API call allows users to connect to an EC2 instance using the SSM service. Multiple `StartSession` requests to the same EC2 instance may indicate an adversary attempting to gain access to the instance for malicious purposes. By default on certain AMI types, the SSM agent is pre-installed and running, allowing for easy access to the instance without the need for SSH or RDP.

- **UUID:** `f9eae44e-5e4d-11ef-878f-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [SSM Start Remote Session to EC2 Instance](../queries/ssm_start_remote_session_to_ec2_instance.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where event.provider == "ssm.amazonaws.com" and event.action == "StartSession"
| dissect aws.cloudtrail.request_parameters "{%{target_key}=%{target_instance}}"
| stats user_instance_counts = count(*) by target_instance, aws.cloudtrail.user_identity.arn, aws.cloudtrail.user_identity.type, event.outcome
```

## Notes

- Use the `target_instance` field to identify the EC2 instance that the user connected to using the SSM service
- Review the `aws.cloudtrail.user_identity*` fields to identify the user making the requests and their role permissions
- The `event.outcome` field can provide additional context on the success or failure of the `StartSession` request
- Identify if the EC2 instance was recently launched by filtering `event.action` field for `RunInstances` API calls. If the instance was not recently launched, investigate further
- Sessions started from IAM users may be benign, but sessions where the `aws.cloudtrail.user_identity.type` is `AssumedRole` are suspicious as they indicate instance to instance connections.

## MITRE ATT&CK Techniques

- [T1021.007](https://attack.mitre.org/techniques/T1021/007)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: ssm rare sendcommand code execution

# SSM Rare SendCommand Code Execution by EC2 Instance

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a single `SendCommand` API call is made by an EC2 instance to execute a command via the AWS Systems Manager (SSM) service within the last 7 days. The `SendCommand` API call allows users to remotely execute commands on EC2 instances. Default documents like `AWS-RunPowerShellScript` and `AWS-RunShellScript` are commonly used for this purpose. Adversaries may abuse this API to execute arbitrary commands on compromised EC2 instances.

- **UUID:** `1844f2d6-5dc7-11ef-b76c-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [SSM Rare SendCommand Code Execution by EC2 Instance](../queries/ssm_rare_sendcommand_code_execution.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| where event.provider == "ssm.amazonaws.com" and event.action == "SendCommand"
| dissect aws.cloudtrail.request_parameters "%{}documentName=%{document_name},%{}"
| dissect aws.cloudtrail.response_elements "%{}instanceIds=[%{instance_id}],%{}"
| where document_name in ("AWS-RunPowerShellScript","AWS-RunShellScript") and instance_id != "*"
| stats user_command_counts = count(*) by instance_id
| where user_command_counts == 1
```

## Notes

- With count 1, this rule will only trigger once for each unique value of the `instance_id` field that has not been seen making this API request within the last 7 days.
- Use the `instance_id` field to identify the EC2 instance that executed the command. This instance ID can be used to search for all related activities, focusing on `event.action` and `aws.cloudtrail.request_parameters` fields.
- The `parameter` field in the `aws.cloudtrail.request_parameters` contains the command executed by the EC2 instance, however is masked in the query to prevent sensitive data exposure by AWS. Reviewing commands executed on the instance can provide context on the adversary's actions.

## MITRE ATT&CK Techniques

- [T1651](https://attack.mitre.org/techniques/T1651)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: sns direct to phone messaging spike

# SNS Direct-to-Phone Messaging Spike

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query gathers evidence of potential abuse of the SNS service to send direct-to-phone text messages. Adversaries may use this technique to send smishing messages or deliver other types of malicious content directly to users' phones.

- **UUID:** `21e4d0ee-e955-11ef-8c29-f661ea17fbce`
- **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
- **Language:** `[ES|QL]`
- **Source File:** [SNS Direct-to-Phone Messaging Spike](../queries/sns_direct_to_phone_messaging_spike.toml)

## Query

```sql
from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| KEEP target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30
```

## Notes

- AWS removes phone numbers in logs, so deeper analysis via CloudWatch logs may be necessary.
- While investigating in CloudWatch, the message context is also sanitized. It would be ideal to investigate the message for any suspicious URL links being embedded in the text messages.
- You can also review AWS SNS delivery logs (if enabled) for message metadata.
- If messages are not using a topic-based subscription, it suggests direct targeting.
- The source of these requests is important, if you notice them from an EC2 instance, that is rather odd or Lambda may be an expected serverless code
- Review if `aws.cloudtrail.user_identity.access_key_id` exists in the CloudTrail audit log, then this request was accomplished via the CLI or programmatically. These keys could be compromised and warrant further investigation.
- If direct SMS messages are common in your environment, you can adjust the threshold accordingly.

## MITRE ATT&CK Techniques

- [T1660](https://attack.mitre.org/techniques/T1660)

## License

- `Elastic License v2`