Skip to content

Commit

Permalink
Update latest docs (#5665)
Browse files Browse the repository at this point in the history
  • Loading branch information
protectionsmachine authored Aug 6, 2024
1 parent 411bbc9 commit b7e8580
Show file tree
Hide file tree
Showing 113 changed files with 7,398 additions and 221 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
[[prebuilt-rule-8-14-8-accepted-default-telnet-port-connection]]
=== Accepted Default Telnet Port Connection

This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic.

*Rule type*: query

*Rule indices*:

* packetbeat-*
* auditbeat-*
* filebeat-*
* logs-network_traffic.*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

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

*Maximum alerts per execution*: 100

*References*: None

*Tags*:

* Domain: Endpoint
* Use Case: Threat Detection
* Tactic: Command and Control
* Tactic: Lateral Movement
* Tactic: Initial Access

*Version*: 105

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Rule query


[source, js]
----------------------------------
(event.dataset:network_traffic.flow or event.category:(network or network_traffic))
and event.type:connection and not event.action:(
flow_dropped or flow_denied or denied or deny or
flow_terminated or timeout or Reject or network_flow)
and destination.port:23
----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Command and Control
** ID: TA0011
** Reference URL: https://attack.mitre.org/tactics/TA0011/
* Tactic:
** Name: Lateral Movement
** ID: TA0008
** Reference URL: https://attack.mitre.org/tactics/TA0008/
* Technique:
** Name: Remote Services
** ID: T1021
** Reference URL: https://attack.mitre.org/techniques/T1021/
* Tactic:
** Name: Initial Access
** ID: TA0001
** Reference URL: https://attack.mitre.org/tactics/TA0001/
* Technique:
** Name: Exploit Public-Facing Application
** ID: T1190
** Reference URL: https://attack.mitre.org/techniques/T1190/
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
[[prebuilt-rule-8-14-8-aws-ec2-instance-console-login-via-assumed-role]]
=== AWS EC2 Instance Console Login via Assumed Role

Identifies a successful console login activity by an EC2 instance profile using an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance and a successful `ConsoleLogin` or `GetSigninToken` API call.

*Rule type*: eql

*Rule indices*:

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

*Severity*: high

*Risk score*: 73

*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://redcanary.com/blog/aws-sts/
* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html/

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS EC2
* Data Source: AWS STS
* Use Case: Identity and Access Audit
* Tactic: Lateral Movement
* Tactic: Credential Access

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Rule query


[source, js]
----------------------------------
any where event.dataset == "aws.cloudtrail"
and event.provider == "signin.amazonaws.com"
and event.action in ("ConsoleLogin", "GetSigninToken")
and event.outcome == "success"
and aws.cloudtrail.user_identity.type == "AssumedRole"
and stringContains (user.id, ":i-")
----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Lateral Movement
** ID: TA0008
** Reference URL: https://attack.mitre.org/tactics/TA0008/
* Technique:
** Name: Remote Services
** ID: T1021
** Reference URL: https://attack.mitre.org/techniques/T1021/
* Sub-technique:
** Name: Cloud Services
** ID: T1021.007
** Reference URL: https://attack.mitre.org/techniques/T1021/007/
* Technique:
** Name: Use Alternate Authentication Material
** ID: T1550
** Reference URL: https://attack.mitre.org/techniques/T1550/
* Sub-technique:
** Name: Application Access Token
** ID: T1550.001
** Reference URL: https://attack.mitre.org/techniques/T1550/001/
* Tactic:
** Name: Credential Access
** ID: TA0006
** Reference URL: https://attack.mitre.org/tactics/TA0006/
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
[[prebuilt-rule-8-14-8-aws-ec2-instance-interaction-with-iam-service]]
=== AWS EC2 Instance Interaction with IAM Service

Identifies when an EC2 instance interacts with the AWS IAM service via an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. For example, an assumed role could be used to create new users for persistence or add permissions for privilege escalation. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance.

*Rule type*: eql

*Rule indices*:

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

*Severity*: medium

*Risk score*: 47

*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://redcanary.com/blog/aws-sts/

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS EC2
* Data Source: AWS IAM
* Use Case: Identity and Access Audit
* Tactic: Privilege Escalation
* Tactic: Persistence

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Rule query


[source, js]
----------------------------------
any where event.dataset == "aws.cloudtrail"
and event.provider == "iam.amazonaws.com"
and aws.cloudtrail.user_identity.type == "AssumedRole"
and stringContains (user.id, ":i-")
----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Persistence
** ID: TA0003
** Reference URL: https://attack.mitre.org/tactics/TA0003/
* Technique:
** Name: Account Manipulation
** ID: T1098
** Reference URL: https://attack.mitre.org/techniques/T1098/
* Sub-technique:
** Name: Additional Cloud Credentials
** ID: T1098.001
** Reference URL: https://attack.mitre.org/techniques/T1098/001/
* Sub-technique:
** Name: Additional Cloud Roles
** ID: T1098.003
** Reference URL: https://attack.mitre.org/techniques/T1098/003/
* 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/
* Tactic:
** Name: Privilege Escalation
** ID: TA0004
** Reference URL: https://attack.mitre.org/tactics/TA0004/
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
[[prebuilt-rule-8-14-8-aws-iam-compromisedkeyquarantine-policy-attached-to-user]]
=== AWS IAM CompromisedKeyQuarantine Policy Attached to User

This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly.

*Rule type*: eql

*Rule indices*:

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

*Severity*: high

*Risk score*: 73

*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/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html/
* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.html/

*Tags*:

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

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and Analysis*



*Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User*


The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials.
This action is accompanied by a support case which specifies instructions to follow before detaching the policy.


*Possible Investigation Steps*


- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity.
- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine.
- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case.
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities.
- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key.


*False Positive Analysis*


- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials.


*Response and Remediation*


- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials.
- **Policy Update**: Review and possibly update your organization’s policies on credential storage to tighten control and prevent public exposure.
- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.


*Additional Information:*


For further guidance on managing and securing credentials in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS IAM User Guide] regarding security best practices and guidance on https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html[Remediating Potentially Compromised AWS Credentials].


==== Rule query


[source, js]
----------------------------------
any where event.dataset == "aws.cloudtrail"
and event.action == "AttachUserPolicy"
and event.outcome == "success"
and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Credential Access
** ID: TA0006
** Reference URL: https://attack.mitre.org/tactics/TA0006/
* Technique:
** Name: Unsecured Credentials
** ID: T1552
** Reference URL: https://attack.mitre.org/techniques/T1552/
Loading

0 comments on commit b7e8580

Please sign in to comment.