Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,212 @@
[[prebuilt-rule-8-18-14-aws-access-token-used-from-multiple-addresses]]
=== AWS Access Token Used from Multiple Addresses

This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts.

*Rule type*: esql

*Rule indices*: None

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-32m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS IAM
* Data Source: AWS CloudTrail
* Tactic: Initial Access
* Use Case: Identity and Access Audit
* Resources: Investigation Guide

*Version*: 103

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and Analysis*



*Investigating AWS Access Token Used from Multiple Addresses*


Access tokens are bound to a single user. Usage from multiple IP addresses may indicate the token was stolen and used elsewhere. By correlating this with additional detection criteria like multiple user agents, different cities, and different networks, we can improve the fidelity of the rule and help to eliminate false positives associated with expected behavior, like dual-stack IPV4/IPV6 usage.


*Possible Investigation Steps*


- **Identify the IAM User**: Examine the `aws.cloudtrail.user_identity.arn` stored in `user_id` and correlate with the `source.ips` stored in `ip_list` and `unique_ips` count to determine how widely the token was used.
- **Correlate Additional Detection Context**: Examine `activity_type` and `fidelity_score` to determine additional cities, networks or user agents associated with the token usage.
- **Determine Access Key Type**: Examine the `access_key_id` to determine whether the token is short-term (beginning with ASIA) or long-term (beginning with AKIA).
- **Check Recent MFA Events**: Determine whether the user recently enabled MFA, registered devices, or assumed a role using this token.
- **Review Workload Context**: Confirm whether the user was expected to be active across multiple cities, networks or user agent environments.
- **Trace Adversary Movement**: Pivot to related actions (e.g., `s3:ListBuckets`, `iam:ListUsers`, `sts:GetCallerIdentity`) to track further enumeration.


*False Positive Analysis*


- Automation frameworks that rotate through multiple IPs or cloud functions with dynamic egress IPs may cause this alert to fire.
- Confirm geolocation and workload context before escalating.


*Response and Remediation*


- **Revoke the Token**: Disable or rotate the IAM credentials and invalidate the temporary session token.
- **Audit the Environment**: Look for signs of lateral movement or data access during the token's validity.
- **Strengthen Controls**: Require MFA for high-privilege actions, restrict access via policy conditions (e.g., IP range or device).


*References*


- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html[IAM Long-Term Credentials]
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[STS Temporary Credentials]
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html[Using MFA with Temporary Credentials]
- https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html[AWS Threat Detection Use Cases]


==== Rule query


[source, js]
----------------------------------
from logs-aws.cloudtrail* metadata _id, _version, _index
| where @timestamp > now() - 30 minutes
and event.dataset == "aws.cloudtrail"
and aws.cloudtrail.user_identity.arn is not null
and aws.cloudtrail.user_identity.type == "IAMUser"
and source.ip is not null
and aws.cloudtrail.user_identity.access_key_id is not null
and not (
user_agent.original like "*Terraform*" or
user_agent.original like "*Ansible*" or
user_agent.original like "*Pulumi*"
)
and `source.as.organization.name` != "AMAZON-AES"
and not ((
`source.as.organization.name` == "AMAZON-02" and aws.cloudtrail.event_category == "Data"))
and event.provider not in (
"health.amazonaws.com", "monitoring.amazonaws.com", "notifications.amazonaws.com",
"ce.amazonaws.com", "cost-optimization-hub.amazonaws.com",
"servicecatalog-appregistry.amazonaws.com", "securityhub.amazonaws.com",
"account.amazonaws.com", "budgets.amazonaws.com", "freetier.amazonaws.com"
)

| eval
Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),
Esql.aws_cloudtrail_user_identity_arn = aws.cloudtrail.user_identity.arn,
Esql.aws_cloudtrail_user_identity_access_key_id = aws.cloudtrail.user_identity.access_key_id,
Esql.source_ip = source.ip,
Esql.user_agent_original = user_agent.original,
Esql.source_ip_string = to_string(source.ip),
Esql.source_ip_user_agent_pair = concat(Esql.source_ip_string, " - ", user_agent.original),
Esql.source_ip_city_pair = concat(Esql.source_ip_string, " - ", source.geo.city_name),
Esql.source_geo_city_name = source.geo.city_name,
Esql.source_network_org_name = `source.as.organization.name`,
Esql.source_ip_network_pair = concat(Esql.source_ip_string, "-", `source.as.organization.name`),
Esql.event_timestamp = @timestamp

| stats
Esql.event_action_values = values(event.action),
Esql.event_provider_values = values(event.provider),
Esql.aws_cloudtrail_user_identity_access_key_id_values = values(Esql.aws_cloudtrail_user_identity_access_key_id),
Esql.aws_cloudtrail_user_identity_arn_values = values(Esql.aws_cloudtrail_user_identity_arn),
Esql.source_ip_values = values(Esql.source_ip),
Esql.user_agent_original_values = values(Esql.user_agent_original),
Esql.source_ip_user_agent_pair_values = values(Esql.source_ip_user_agent_pair),
Esql.source_geo_city_name_values = values(Esql.source_geo_city_name),
Esql.source_ip_city_pair_values = values(Esql.source_ip_city_pair),
Esql.source_network_org_name_values = values(Esql.source_network_org_name),
Esql.source_ip_network_pair_values = values(Esql.source_ip_network_pair),
Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),
Esql.user_agent_original_count_distinct = count_distinct(Esql.user_agent_original),
Esql.source_geo_city_name_count_distinct = count_distinct(Esql.source_geo_city_name),
Esql.source_network_org_name_count_distinct = count_distinct(Esql.source_network_org_name),
Esql.timestamp_first_seen = min(Esql.event_timestamp),
Esql.timestamp_last_seen = max(Esql.event_timestamp),
Esql.event_count = count()
by Esql.time_window_date_trunc, Esql.aws_cloudtrail_user_identity_access_key_id

| eval
Esql.activity_type = case(
Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, "multiple_ip_network_city_user_agent",
Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, "multiple_ip_network_city",
Esql.source_ip_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, "multiple_ip_and_city",
Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2, "multiple_ip_and_network",
Esql.source_ip_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, "multiple_ip_and_user_agent",
"normal_activity"
),
Esql.activity_fidelity_score = case(
Esql.activity_type == "multiple_ip_network_city_user_agent", "high",
Esql.activity_type == "multiple_ip_network_city", "high",
Esql.activity_type == "multiple_ip_and_city", "medium",
Esql.activity_type == "multiple_ip_and_network", "medium",
Esql.activity_type == "multiple_ip_and_user_agent", "low"
)

| keep
Esql.time_window_date_trunc,
Esql.activity_type,
Esql.activity_fidelity_score,
Esql.event_count,
Esql.timestamp_first_seen,
Esql.timestamp_last_seen,
Esql.aws_cloudtrail_user_identity_arn_values,
Esql.aws_cloudtrail_user_identity_access_key_id_values,
Esql.event_action_values,
Esql.event_provider_values,
Esql.source_ip_values,
Esql.user_agent_original_values,
Esql.source_ip_user_agent_pair_values,
Esql.source_geo_city_name_values,
Esql.source_ip_city_pair_values,
Esql.source_network_org_name_values,
Esql.source_ip_network_pair_values,
Esql.source_ip_count_distinct,
Esql.user_agent_original_count_distinct,
Esql.source_geo_city_name_count_distinct,
Esql.source_network_org_name_count_distinct

| where Esql.activity_type != "normal_activity"

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Initial Access
** ID: TA0001
** Reference URL: https://attack.mitre.org/tactics/TA0001/
* Technique:
** Name: Valid Accounts
** ID: T1078
** Reference URL: https://attack.mitre.org/techniques/T1078/
* Sub-technique:
** Name: Cloud Accounts
** ID: T1078.004
** Reference URL: https://attack.mitre.org/techniques/T1078/004/
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
[[prebuilt-rule-8-18-14-aws-dynamodb-scan-by-unusual-user]]
=== AWS DynamoDB Scan by Unusual User

Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time.

*Rule type*: new_terms

*Rule indices*:

* filebeat-*
* logs-aws.cloudtrail-*

*Severity*: low

*Risk score*: 21

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS DynamoDB
* Resources: Investigation Guide
* Use Case: Threat Detection
* Tactic: Exfiltration

*Version*: 4

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS DynamoDB Scan by Unusual User*


This rule identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs.

This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time.


*Possible Investigation Steps*


- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user.
- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access.
- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the Scan request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being scanned.
- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key is associated with a legitimate user or if it has been compromised.



*False Positive Analysis*


- Historical User Actions: If the user has a history of scanning DynamoDB tables for legitimate purposes, this may not be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions.
- Automated Processes: Some automated processes or applications may perform scans on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may not be a false positive.


*Response and Remediation*


- Immediate Review and Reversal: If the Scan action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's account or removing their permissions.
- Investigate Compromise: If the Scan action is determined to be malicious, investigate the source of the request and any potential compromise of the user's account. This may involve reviewing access logs, resetting passwords, and enabling multi-factor authentication (MFA) for the affected user. If export options were used with the CLI or SDK, they may have been saved locally or to a remote location.
- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources.
- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts.


*Additional Information*


For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security.


==== Setup


DynamoDB data events must be enabled in CloudTrail to capture the Scan action. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables.

==== Rule query


[source, js]
----------------------------------
event.dataset: "aws.cloudtrail"
and event.provider: "dynamodb.amazonaws.com"
and event.action: "Scan"
and event.outcome: "success"

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Exfiltration
** ID: TA0010
** Reference URL: https://attack.mitre.org/tactics/TA0010/
* Technique:
** Name: Exfiltration Over Web Service
** ID: T1567
** Reference URL: https://attack.mitre.org/techniques/T1567/
* Tactic:
** Name: Collection
** ID: TA0009
** Reference URL: https://attack.mitre.org/tactics/TA0009/
* Technique:
** Name: Data from Cloud Storage
** ID: T1530
** Reference URL: https://attack.mitre.org/techniques/T1530/
Loading