[Fix] Updating the hunting library

Author: Aegrah

hunting/aws/docs/iam_assume_role_creation_with_attached_policy.md

@@ -26,6 +26,7 @@ from logs-aws.cloudtrail-*
     and aws.cloudtrail.request_parameters RLIKE ".*arn:aws:iam.*"
 | dissect aws.cloudtrail.request_parameters "%{}AWS\": \"arn:aws:iam::%{target_account_id}:"
 | where cloud.account.id != target_account_id
+| keep @timestamp, event.provider, event.action, aws.cloudtrail.request_parameters, target_account_id, cloud.account.id
 ```
 
 ## Notes

hunting/aws/docs/iam_customer_managed_policies_attached_to_existing_roles.md

@@ -1,4 +1,4 @@
-# AWS IAM Customer-Managed Policy Attachment for Privilege Escalation
+# AWS IAM Customer-Managed Policy Attachment to Existing Roles
 
 ---
 
@@ -10,7 +10,7 @@
 - **UUID:** `418baaf2-9ae1-11ef-be63-f661ea17fbcd`
 - **Integration:** [aws.cloudtrail](https://docs.elastic.co/integrations/aws/cloudtrail)
 - **Language:** `[ES|QL]`
-- **Source File:** [AWS IAM Customer-Managed Policy Attachment for Privilege Escalation](../queries/iam_customer_managed_policies_attached_to_existing_roles.toml)
+- **Source File:** [AWS IAM Customer-Managed Policy Attachment to Existing Roles](../queries/iam_customer_managed_policies_attached_to_existing_roles.toml)
 
 ## Query
 
@@ -29,11 +29,11 @@ from logs-aws.cloudtrail*
 
 ## Notes
 
-- Review the `target_account_id` field to verify the AWS account in which the role is being modified, especially if this account is outside of your organization’s typical accounts.
-- Examine `aws.cloudtrail.request_parameters` for details on the role and attached policy. Customer-managed policies granting overly permissive access, such as `AdministratorAccess`, may signal unauthorized privilege escalation.
-- Cross-reference `event.action` values where `AttachRolePolicy` appears to further investigate attached policies that could enable lateral movement or persistence.
-- Evaluate `aws.cloudtrail.user_identity.arn` to confirm if the actor attaching the policy has legitimate permissions for this action. Anomalous or unauthorized actors may indicate privilege abuse.
-- Look for patterns of multiple `AttachRolePolicy` actions across roles by the same user or entity. High frequency of these actions could suggest an attempt to establish persistent control across roles within your AWS environment.
+- Review the `attached_policy_name` and `target_role_name` fields to identify the customer-managed policy and role involved in the attachment.
+- Review the permissions of the attached policy to determine the potential impact of the privilege escalation attempt.
+- Review all entities that `target_role_name` may be attached to as these entities may have been compromised or misused.
+- Consider reviewing the `aws.cloudtrail.user_identity.arn` field to identify the actor responsible for the privilege escalation attempt.
+- Review the user agent of the actor to determine the source of the privilege escalation attempt, such as an AWS CLI or SDK.
 
 ## MITRE ATT&CK Techniques
 

hunting/aws/docs/lambda_add_permissions_for_write_actions_to_function.md

@@ -24,6 +24,7 @@ from logs-aws.cloudtrail-*
 | 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

hunting/aws/docs/signin_single_factor_console_login_via_federated_session.md

@@ -24,6 +24,7 @@ from logs-aws.cloudtrail-*
     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

hunting/aws/docs/ssm_sendcommand_api_used_by_ec2_instance.md

@@ -22,6 +22,7 @@ from logs-aws.cloudtrail-*
     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

hunting/aws/docs/sts_suspicious_federated_temporary_credential_request.md

@@ -26,6 +26,7 @@ from logs-aws.cloudtrail-*
 | dissect aws.cloudtrail.request_parameters "{%{}policyArns=[%{policies_applied}]"
 | eval duration_minutes = to_integer(duration_requested) / 60
 | where (duration_minutes > 1440) or (policies_applied RLIKE ".*AdministratorAccess.*")
+| keep @timestamp, event.dataset, event.provider, event.action, aws.cloudtrail.request_parameters, user_name, duration_requested, duration_minutes, policies_applied
 ```
 
 ## Notes

hunting/okta/docs/defense_evasion_failed_oauth_access_token_retrieval_via_public_client_app.md

@@ -33,6 +33,8 @@ from logs-okta.system*
 
     // filter for scopes that are not implicitly granted
     and okta.outcome.reason == "no_matching_scope"
+
+| keep @timestamp, event.action, okta.actor.type, okta.outcome.result, okta.outcome.reason, okta.actor.display_name
 ```
 
 ## Notes